Three things:

• The actual compiler specific code - this can be in
• Branding - I can manually adjust it here (= in the VMR only) to claim it is v10 and not v11 yet. In the chat I heard a proposal if the versions (like 10.0.200 vs 11.0.0) could be coming at build time via the VMR-orchestrator. Is that doable? For sure, I would prefer not to merge it as is since the current PR would flow 11 to versions of eventually published packages etc.
• Some related infra, like F# main is already on arcade from 11. Is that OK? If it works, I am fine with that.

@premun , @mmitche :

Is it fine if I manually edit the versions.props in the VMR for 10.0.2xx only?
We are flowing our main to both VMR's main (net11) as well as this 10.0.2xx.
The thing is, we have already branding for 11 in our main, and 10.0.200 should not have it.

Can I just edit the content in this PR, or would that backfire in backflow to main and/or as conflicts in upcoming forward flows?

@T-Gro there's no backflow to main from 2xx, right? So it will only potentially conflict on future forward flows if you change that area.

Maybe you could just override the variables lower so that it will be a new block of props (with a comment explaining it) so it's more explicit and less conflict-prone?

That's a clever idea, I have appended this block. Hopefully the PreReleaseVersionLabel "servicing" is correct for this branch,

    <!-- F# Version components - override specific to the 10.0.2xx branch. Reason is, the content comes from F#'s main which is already branded as NET11. We override it here in the VMR only -->
    <FSMajorVersion>10</FSMajorVersion>
    <FSMinorVersion>0</FSMinorVersion>
    <FSBuildVersion>200</FSBuildVersion>
    <FSRevisionVersion>0</FSRevisionVersion>
    <FSharpPreReleaseIteration></FSharpPreReleaseIteration>
    <PreReleaseVersionLabel>servicing$(FSharpPreReleaseIteration)</PreReleaseVersionLabel>
    <!-- End of the custom override related just to 10.0.2xx branch in the VMR -->