In the v14 extensibility model, MSBuild distributed many props and targets as part of its own installer, SDK authors installed files into known locations, and project files imported props and targets using paths relative to the MSBuild install root.

With the advent of Sdks, projects no longer need to specifically specify a path but can address an Sdk by name and version. However, Sdks that wish to opt into common functionality (i.e. all Sdks) still import the core MSBuild targets by the old mechanism that assumes they are next to MSBuild, for example:

<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />

Instead, MSBuild could publish a "Core Sdk" containing a copy of these files, and Sdks could explicitly depend on a versioned copy.

That has two effects, after Sdk version identification is complete:

➕ An Sdk version reference is stable and should work identically on different MSBuild engines (barring changes in behavior).
➖ Merely updating to a new CLI/MSBuild doesn't get you the latest bugfixes/extensibility points from new common targets.