Maybe a little more explanation is in order. I think of toolchain selection in terms of dispatch tables. The top-level dispatches on toolchain type. If the toolchains in the type target multiple targethosts, then we move to the second-level dispatcher, which is controlled by *_compatible_with and target_settings.
Now if my toolchain type only contains toolchains targeting the same targethost, then I don't need target_compatible_with in the second-level dispatch, since targethost constraints are already implicit in the toolchain type. So if I can specify my toolchain type for a build target, I don't need to also specify any (target) platform constraints. Put differently, the value for target_compatible_with (on the toolchain rule) is effectively "any", and that's ok since every available toolchain in fact targets the desired host.
Whether or not such a target should be built at all is a separate issue. The proposal says:
"When a target is being configured, and the value of the
platform attribute is different from the target platform for the configuration, that will be an error and the target will not be built."
I'm not sure that's a good idea. Maybe the user wants it to be built anyway; this should be controlled by target_compatible_with on the build target.
More generally, "platform" is confusing enough already. The platform rule, contrary to what the docs say, does not define a "platform", it only declares a (named) set of constraints, which may or may not be satisfied for a particular build run, and - crucially - need not be used together, as a unit, in toolchain selection. The '--platform=foo' CLI argument effectively means "The constraints associated with foo are hereby satisfied", but the documentation on this is far from clear. All this suggests (to me, at least) that a platform is a first-class thing (in the language), but that's not the case. You cannot write e.g. target_compatible_with=":myplatform", but the proposal is to allow 'platform=":myplatform"'. I think that's just going to confuse a lot of people.
From the proposal: "When built directly, the
platform attribute will be used to set the target platform." But there is no "target platform" to set, there is only a collection of attributes to stipulate. The critical point being that the *compatible_with attributes only traffic in constraints, not platforms, and they are not required to match up point-by-point with any "platform".
Consider what 'platform=":myplatform"' looks like to a beginner. It's an assignment, right? Well, no, it's not. It's there purely for side-effects. Ditto for '--platform=foo' - it does not mean that "platform" should have the value "foo".
The proposal says "The
platform attribute and the
target_compatible_with attribute have similar but distinct functionality. " I think they're completely different animals, just as 'i=3' and 'i: Int' are different animals.
Then of course there is the simple ambiguity of using 'platform' when you mean 'target_platform'.
To sum up, I think the problem addressed by the proposal should be viewed not as "how to indicate a desired target platform for a build rule" but the more fundamental "how to select the desired toolchain", which does not necessarily involve platforms.