I don't find this particular way of distnguishing build elements helpful, mostly because nouns, verbs and adverbs can be fairly easily transformed into one another. Am I a baker who uses flour? A producer of products from flour who uses an oven? A warrior who beats people up with weapons? A weapon-wielder who fights to win?
I mean, the class which started out as magic-user (how one does things, presumably - by using magic) is now called wizard (which presumably names a profession, what it is that one does).
That's true, but there is a distinction, though not a clear-cut one, between how one does things (in terms of mechanics) and what one does (in terms of the non-mechanical fiction.) I probably ought to have used the same term (how/what) for both statements so I could highlight that I meant a mechanics vs. non-mechanics distinction, and not a context-free noun vs. verb. And while in principle just about anything could have corresponding mechanics, I'm mostly talking about the mechanics that D&D has found fit to enshrine in its classes. (In more free-form systems like FATE, where the "Baker" aspect might have a gameplay significance as great as combat abilities, I readily grant your point. In fact, the FATE fractal pretty much embraces that viewpoint to its full extent.) A background like Baker could be consistent with numerous classes or no class at all, and I think it would be difficult to write a D&D class that encompasses what one might mean by Baker without setting down some pretty arbitrary restrictions on what it means, and how it meaningfully affects the outcomes of events in D&D. This is why something like an Assassin background would be so powerful -- it speaks to a non-mechanical role (or at least one with many and varied mechanical implementations) in a sufficiently generic way that almost any class could take it.
I feel that your post takes a very process-simulation approach to PC-build elements. But we needne't do that.
Heh, well, it wouldn't be the first time.

My intention is not to force the mindset of simulation, however, despite my use of "represents" many times in the original post. (It's true I do want consonance between story and mechanics, but which of story or mechanics might bend to fit the other isn't my concern here.) Whether one uses simulationistic mechanics or not, the division of labor between backgrounds, classes, and feats I suggested is designed to give each element mechanical distinction since mechanical distinctions can be discerned objectively while story distinctions are subjective and often nebulous. I accept that there are many story representations of Assassin that might make sense for backgrounds, classes, feats, etc. That being the case, clear mechanical roles cannot be determined primarily on the basis of story, although the story can inform the nuances. If I were to write the post a second time I might state the mechanical bits first and say "Class
typically represents the fundamental interaction with the setting's reality" and so on. Then it would more clearly function as a bit of guidance rather than proscription and the player/designer could be first inspired by a nifty mechanic or the story and go from there.
This is why I don't think the issue of fighter subclasses, for instance, has to be a decision between generic fighting styles vs. more cultural categories like samurai (although if push came to shove I'd probably choose the former.) There is room for both, but each should embrace its own approach fully. A generic style could be potentially compatible with many story identifications (including samurai) while a samurai subclass should embrace the unique characteristics of being a samurai (e.g. a bushido mechanic built on top of expertise dice) as part of its backbone. Making sure that the mechanics (and to a lesser extent the "typical story") of different game elements have a clear place supports multiple approaches in this manner. I
want multiple approaches, but not if the cost is an amorphous mechanical blob.
For instance, suppose the difference between "feat" and "class" is "little mechanical element" and "big bundle of mechanical elements with a whole range of sizes". Then, in choosing the "gladiator" feat I am choosing to make gladiating only a modest part of my PC's overall mechanical build. Whereas in choosing the "gladiator" sub-class I am choosing to make gladiating a very rich part of my PC's overall mechanical build.
But neither choice has necessary implications for how big gladiating is in the story of my PC. On either build it might be that gladiating is a big part of who my PC is, or a small part.
Ahh, but if a single level of a class may also be a smallish bundle of mechanical element what distinguishes feats from self-contained single-level class features? Aside from the fundamental class mechanics like spells, the answer is probably not much unless one makes all feats significantly more or less powerful than what is gained from a class level. In fact, if 3e-style multiclassing is present (and assuming a gladiator class) we now have at least two ways to gain modest gladiatorial abilities, and the distinction between "class feature" and "feat" is particularly murky. If feats were gladiatorial breadth (independent mechanics) and class were gladiatorial depth (dependent mechanics) we could start to see a unique place again. (Note that I am not saying there can only be one way to give classes, feats, etc. this kind of structure, just that "size alone" is insufficient without other structural considerations.)
The story of the PC didn't change particularly over the course of these rebuilds (though in some ways it got richer) - rather, different mechanical elements were added and subtracted which change the way the PC is expressed in play.
Furthermore, the real character of the PC is as a sage and ritualist, even though - because the game is 4e - the single biggest area of the character sheet deals with combat-relevant abilities. So in play the PC is expressed very much via combat abilities - but this doesn't mean that the PC's background and character isn't that of a sage.
I'm not sure I consider that a counterexample to my perspective. A character need not have the (non-existent?) sage class to be considered a sage within the fictional reality, whether its class is wizard or invoker. The mechanical and role-playing decisions made at other points can certainly support that identification. Heck, in 3.5 I helped make a sage ranger for another player that was quite fun at the table. However, if the character identifies primarily as a sage, if there were a class whose combat abilities clearly had a sage-like feel, would the character not give that some consideration, perhaps just for multiclassing? In fact, I think 4e's feat-based approach to multiclassing (despite my misgivings about using feats in the first place) marvelously succeeded in giving those feats a clear relationship to class features. A person who homebrewed their own class could make a reasonable multiclass feat with very little effort because it was clear what was expected and permitted, and a player could discern this just as quickly. If 5e could approach a similar mechanical clarity of purpose (if not quite mechanical rigidity) for its various elements, I think I would find a lot to like.
As always, I have appreciated your in-depth thoughts.