It seems as if neither of us is completely clear on what, if anything, our disagreement is about, because we seem to agree on most things and are merely confused about where the other person is disagreeing.
I anticipated that when I wrote: "I think the misunderstanding is coming from the vague idea "mechanics". We have agreed that they are out there, but we haven't really spoken on what they are like. This would be easier if we had a common frame of reference."
We both agree that before we can expect a game to feature interesting play around a concept that there needs to be some sort of system that supports that concept in an interesting way. You wrote, correctly, "You can't build a mechanically-interesting class solving mysteries, for example, unless there's a framework in place for how you would mechanically solve mysteries."
I think we both agree that different scenarios require different mechanical support to capture the peculiarities of the problem. That is to say, it is usually a mistake to (as some have done), try to support both social interaction and physical combat with the same system, unless you also call out the differences between the two in some way. I'm thinking of for example 'Dogs in the Vineyard' which features some of the strongest joint mechanics for both social interaction and physical combat that I've seen in any system, but which (correctly I think) calls out that physical combat trumps social interaction. That said, DitV isn't intended to support (among other things) tactical combat and if you were wanting to run a game with tactical combat as one of the intellectual interests of the game you'd be disappointed in the results.
Where I may have misunderstood you, or where we may not agree, is on what makes for interesting character design when a system has diverse subsystems. When you wrote,
"Otherwise you wind up with something both bland and redundant like "you get advantage on all your skill checks related to solving mysteries", instead of "Once per Episode, you can make an intuitive leap to Find A Clue automatically without needing to Notice the corresponding signs first." is where I found some room to quibble with.
I took this to mean that you believed that the character creation subsystem in order to meaningfully interact with a subsystem needs to have that subsystem in its scope and needs to know the subsystems details. And not only do I disagree, I would consider this bad design, for very similar reasons that it is bad design to have those sorts of dependencies in object oriented code. It would be wrong to expect that the character creation designer fully understands the scope and details of all the subsystems that may eventually be a part of the system. All the character creation designer needs to understand is that at some point somebody is going to want to create that subsystem and he needs to provide a strong interface with character design for that system.
Otherwise, what happens is that if I want to write a Mystery/Investigation subsystem to extend the system, I find that I have to create new classes to meaningfully interact with the new subsystem, and if I do that, I haven't created one game where in one session we can have exciting tactical combat, and in the text we can have an exciting murder mystery. I instead have created two games that require very different characters, each of which might not be able to fully interact with the other system.
Now, this sort of design is really common in RPG history, but I think its also subtly wrong and we ought to know better now. Pathfinder is having problems right now along theses lines. Further back, GURPS is an excellent example, precisely because you wouldn't expect it to be. GURPS bills itself a generic universal system, which is true, but once you become familiar with it you realize that is not a generic, universal,
coherent system. You could port a Supers character to a non-Supers universe, and the rules would allow you to understand the interaction, but the character is built on such different expectations that it would in no way be balanced. You wouldn't (or maybe shouldn't) allow Supers resources in a generic fantasy game. You could build a character with psionics, but psionics is built on the assumption of parity with guys wielding machine guns and lasers, not swinging swords. If you ported your psionics character to a generic fantasy game with magic, he'd not be balanced with the magic wielder who is built on the assumption of being balanced with sword-slingers. All the subsystems use the same base rules, but they aren't really meant to be used together. Instead, the core mechanics are used to create a bunch of different non-interacting game ideas.
What I would argue is that if you have an elegant design, such as 5e, you can create an interesting subsystem that is not integral to the game but which is fully integratable with the game. You do it really through the same way you'd do dependency injection, by stubbing out an interface the details of which you do not need to know. And further, I would argue that this is the most interesting way to do it. So for example, when I write mechanics for the subsystem like, "If you are proficient in Perception, you automatically notice Hidden Clues without needing to roll.", the fact that a character like a Bard or a Ranger - which isn't built with solving Murder Mysteries and being a viable detective in mind - nonetheless meaningfully interacts with the subsystem is a feature and not a bug. In that sense, that my Detective class has 'boring' abilities like, "You have proficiency in Perception, Insight, and Investigation..." is actually exciting provided my Mystery/Investigation subsystem is also exciting, both because he meaningfully interacts with the subsystem and has spot light, and because the Detective class is still fully useable when we aren't playing a game entirely focused on that subsystem. And if you have an existing group of characters, not specifically focused around Intrigue or Mysteries, and your DM decides to buy the Mystery subsystem, your characters are still meaningfully interacting with this system.
Compare with the case where I design the Detective class based on detailed knowledge of the Mystery/Investigation subsystem. In that case, the Mystery/Investigation game is the only one that I can meaningfully be a part of, as most of my abilities are called out as only interacting with that subsystem. Likewise, in this case, if some GM decides to homebrew his own Mystery/Investigation subsystem, he finds he has to make changes everywhere in the game to make his new subsystem compatible.
what you call "proposition validation" and the Alexandrian calls "game structure"....
I like my term better. It's less vague.
