You raise good points as always. But you're making assumptions and stepping past a very big world of functionality as if it isn't there. So, to answer a simple question like this:
If so, I don't see any time/efficiency being saved by not filtering object types in the dialogues for points, lines, and areas?
... I have to get into a discussion of that big world you've stepped past. The short answer is that filtering object types in the thematic format list is throwing away data, but it is data that you have declared is important to you. It wastes time and causes inefficiency to use powerful facilities to group data, in a way that you say is the essence of what you want to do, and to then throw away some of the data you say you want to see.
Given the possible confusion that seems to be in play here, it takes a fair number of words to clarify that. And there's none of this "Yeah, beating the drum about good data organization. I get that. Now let's ignore that drumbeat... " allowed if you want to get to the powerful logic of how to use the thing effectively. :-)
In order to do the formatting with the style pane, we go to the controlling color button for each object type and apply the thematic formatting. Perhaps I'm missing something but is that not what we must do? If so, I don't see any time/efficiency being saved by not filtering object types in the dialogues for points, lines, and areas?
The Style dialog serves two purposes. It provides instant changes applying the same setting, and it also allows per-object changes using thematic formatting. When you apply thematic formatting, you're doing it to a layer where all objects are in there for a reason, because they all share the same intent of thematic formatting by a specific field. If they don't (like your Release 8 example), they don't belong in the same layer.
If you intend to apply a thematic format, mixing objects together in a layer to which your thematic format will be applied is a declaration on your part that those objects that have been mixed together belong together because they have a field in common where the variation in values in that field makes sense as a control for all of the objects in that layer. If that's not the case, it was an error on your part to mix the objects together in the same layer. Better to organize them in different layers.
The above is talking about thematic formatting. That's just one of the ways we might want to style objects. The other situation is where we just want to apply the same color or symbol to, say, all points or all lines. In that case you don't care about a common field value, but you just want to click on controls quickly to achieve some visual effect.
In both situations, there are controls which serve the same, or almost the same, function, so it helps to keep the same what controls can be kept in common, the old "orthogonality" bit.
To get back to your question, answering it from a slightly different approach:
Perhaps I'm missing something but is that not what we must do? If so, I don't see any time/efficiency being saved by not filtering object types in the dialogues for points, lines, and areas?
The "why" has a lot to do with two key intents: a) your intent in keeping areas, lines and points together in the same layer, and b) your intent in applying a thematic format to any of those objects.
The following is a key sentence, because habits in GIS have often been developed in a way that opposes efficient exploitation of data:
it might make sense setting up data in a way, perhaps temporarily, that isn't normal practice.
Consider key intent a), why somebody keeps areas, lines and points together in the same layer. This often is an example of "normal practice" in GIS that is opposed to efficient exploitation of data. That happens when people dump points, lines and areas into the same layer just for the convenience of keeping everything in one layer (turning it on/off, copying/pasting, etc.). and not because the areas, lines and points have any functional commonality in attributes.
Suppose somebody wants to mobilize a community action group to get more trees planted in a town. That person might create a layer - one drawing - for a town that shows the city council voting precincts as areas, the streets as lines, and many points that are a mix of points which show the locations of existing trees as well as the addresses of people who are ready to be volunteers to go out to knock on doors. He wants to get people organized in the various precincts of the various city council members to put grass roots voting pressure in action to get more trees planted. That's a mess of an organization to put data with four very different purposes into the same layer, but hey, people do such things all the time.
Historically, GIS packages have been wretched at data management, so that's one reason why you have so many forums full of people asking "hard to get there from here" questions because they did things like mix in all their volunteer points with tree location points. It is a well-beaten drum to say "organize your data with clarity", but because of the facilities offered in classic GIS it is also often a well-ignored drum in normal practice.
Setting up data with clarity and good organization, if your GIS package can handle it, is always a good idea as your foundation, not as a temporary measure.
In the case of 9, the unit is a project where you can have as many layers as you want. There is no need to artificially group dissonant objects together in the same layer, or, the obverse mistake to fail to group consonant objects together in the same layer, because of any artificial restrictions on grouping or lack thereof in the storage format.
If you choose to group your data into one layer, and you intend to apply thematic formatting to that data, then you darned well should have chosen the data to put into that one layer because it has values in fields that are the essence of your thematic format that are common to all of the objects in that layer.
In order to do the formatting with the style pane, we go to the controlling color button for each object type and apply the thematic formatting. Perhaps I'm missing something but is that not what we must do?
Yes, that's exactly right, and that is just as true for thematic formatting as it is for direct formatting. When you want to apply thematic formatting and mix areas, lines and points in the same layer, you do that because they have a common association in their attributes that you intend to use in a thematic format.
That association could be explicit, like all of the objects having a common field containing a value, such as the date the data was acquired, that is the same for all of them and thus it makes sense for all of them to be in the same layer, or it might be an implicit association, such as "OK, these are all the Ft.Worth objects in this layer, and the Dallas objects are in that layer over there..."
In such cases, any direct formatting you do is typically a one-click operation on symbology or colors or sizes where you just want all the objects of that particular type to be styled a particular way. It is very convenient in that case that you have controls that apply style by object type.
Thematic formatting is a very different case logically, because, while it also varies style properties, it varies them on the basis of a field as the primary control. If thematic formatting is your intention, you should not mix objects in the same layer which do not have the controlling field in common - complete with values in that field - that you intend to use as the guide for thematic formats.
If you vary the appearance of something based on a field, the value of that field better be something that you care about. If there are objects that don't have a value in that field (NULLs) or which are so alien that any mention of that field makes no sense with them, well, then they simply don't belong in that layer to which you apply thematic formatting based on that field. It's simply a mistake to have mixed them in. [I emphasize I don't mean "mistake" because of some abstract desire to be politically correct in DBMS theory, I mean "mistake" in the practical sense of causing yourself extra work and unpleasantness that is easily avoided by doing it right. It's like Sonny mixing all the different material bolts together in the same bucket.]
When you put objects into a layer that is to be thematically formatted by some field, you are saying "This field is important to me. It's what I care about, and what I want to show where and how it varies." You shouldn't be putting objects into that layer which don't participate in that field.
If using unique values in the point thematic dialogue, do I really want to have an option to apply a color to values associated with lines or areas? That just adds clutter to the dialogue.
That's a very good question, but you get a wrong answer if you assume it is OK to mix objects together in a layer where the mixing of them works directly against what you say is important to you.
First, it is not an "option" to show all records in a thematic formatting dialog. It is the primary reason to have the dialog in the first place. It's supposed to show all the records, because that's why you put them all together. [If you didn't intend to mix them all together but they all just fell into the same bucket without you realizing it, well... that's a different problem. Also solvable easy enough, but it's a different problem.]
When you mix points, lines and areas in a layer to which you intend to apply a thematic format, you are declaring two things: you are saying they all have some field in common with values that are important to you, and that thematic formatting based on that field makes sense despite the disparity in object type. If both of those things are not true, almost certainly you made a mistake mixing the objects together in the same layer.
That latter bit is subtle, but it is powerful, and it does frequently arise, for example, in cases where you might be changing areas to their centroids, areas to lines on the boundary of areas, or where you might be creating additional geometry in the same record, for example, having parcels in a record both as area objects and also as a computed field giving the inner center.
If the reply to the above is , "Well, gee, I didn't intend any of that and none of that is important to me. I just inherited this data the way it is and now I want to make some visual distinctions to what I care about with points."
To that I say, OK, easy to do it the right way: Take two clicks to select the points and put them in their own layer. You can now do what you want with the points without being distracted by having a lot of objects mixed in that don't have anything to do with what you want to accomplish. Takes less than ten seconds.
Suppose the reply is, "Well, fine, but I don't want to spend even ten seconds. I just want to hack at this right now and color points. 8 let me do that, by hiding any interval numbers associated with lines or areas."
I look at that and I ask, "what's the intent of coloring the points? Is the way 8 does it the best and easiest way?" As they say, the road to you-know-where is paved with a combination of good intentions and cutting-corners laziness, so it pays to take a moment to consider very carefully if you really do want to set foot on a path that very quickly might lead you into more of a mess.
If the reason you want to thematically format points has to do with an attribute those points have where it is important to you to use visual appearance to show differences in values in that attribute, and where the lines and areas really do not participate in that attribute, then most frequently it is a terrible error to not take a moment to move those points into their own layer. That is true for a long term reason and for a short term reason.
The long term reason is beating that drum about organizing your data clearly, having the foresight to keep your bolts of different materials in different bins and not letting a guy like Sonny mix them together.
The short term reason is to avoid having controls like those in 8 which show things not as they really are. If you do a thematic format on points with just, say, two intervals in 8 and it excludes the lines and areas, the numbers you see won't add up to the total number of records the table says it has.
That will be puzzling to anyone who thinks that a histogram reporting what is in a field should report what is in there, without silently ignoring some of the records. It will also be puzzling to those people who are trying to set up a thematic format for a table that is not yet fully populated, either because the points have not all be created or because they want to set up an arrangement that will continue to work as they want when areas and lines might later be changed into centroid points.
Such puzzlement is related to what are the best controls if, indeed, you do want filtration.
You might say, "OK, I get all that, but right now I have good reasons why I want to mix points, lines and areas together, and for the sake of convenience I really do want to see only intervals that have to do with points when I click the thematic formatting button for points."
What is the best control to do that? What's "best" isn't just what works in one special case, at the cost of confusing the dickens out of everybody else in other cases. The control also should not be something that assumes people aren't ever going to learn to do it right. It has to make sense for people who are doing it right, also.
In that context, I don't think the way 8 does it is a good approach: it automatically hides part of the data in the table, the records that have to do with lines and areas, when it computes intervals for points. By doing so, it shows "wrong" statistics for anybody who is also looking at the associated table that doesn't hide data for lines and areas. It also prevents you from setting up a thematic format for situations where object types change, that is, reducing capability, flexibility and orthogonality.
OK, so one approach is to put a filter button on it. That's explicit. But it is also slightly risky, in that beginners will have to learn to push that filter button, and any need to RTFM is a risk. And then you have to pay attention to the setting of a button in terms of understanding what you are doing.
An even worse risk is that it continues what 8 does, which is to encourage a too-loose approach to data, just hacking at it instead of taking a moment to structure it in a way that makes the task easier now and in the future. It's the old "Yeah, I should take a moment to fix this but right now I just want to color it...". As they say, "Nothing is as permanent as a temporary solution."
Compare that to a different way of providing a "filter button:" use the infrastructure that is already there, which requires no remembering of secret handshakes or button settings. If you want to format points in a thematic format without being confused by lines or areas that have nothing to do with those points, well, take ten seconds to move those points into their own layer. Done.
You then have layer structure, a really obvious infrastructure thing with no hidden machinery, that controls everything in a crisp, obvious, hard-to-get-wrong way. It also has the wonderful side effect of grouping data that has some commonality in what it means as data within the same table, so that naturally the shared meaning of data can be used for visualization, as in thematic formatting.
If the push back on that is a desire to share related thematic formats more easily between different layers, well, that's easy enough to do. It could be made even easier, as with a simple "Copy" on one style property in one layer and a "Paste" onto another. But that's a somewhat different theme in terms of how one can construct thematic formats for one drawing and then recycle some of that arrangement into different drawings.
So far, all this is talking around the edges. What really helps in nailing down some of these concepts is a discussion of real world data and real world tasks.
I want to emphasize there's no resistance of any kind to making anything easier and quicker. There's only the question of what is the best way to do that. There is also some understandable resistance to making one special case easier at the cost of creating misery in other settings, and a respectful insistence that if there is a very powerful way to do something desired that is easy and already there, to see if perhaps whatever is preventing that from being used can be removed, before introducing something else that may or may not be easier or better.