Core-Setup release/3.1 contains some managed libraries. When they don't have a change, they shouldn't build as part of the servicing release. (Downstream repos should continue using the old version.)

Alternative A: manually disable

We can remove the managed projects from the build entirely when not wanted.

In 2.1, this removal is a little buried in this file:
https://github.com/dotnet/core-setup/blob/ba3b934aa42697c3faaebfaa1622cdea2f10ff75/src/pkg/packaging/dir.proj#L169-L177

In 3.1, it's over here:
https://github.com/dotnet/core-setup/blob/d59676539b88da3576c20e2150b09323f280c437/Subsets.props#L64-L73

Alternative B: automatic disable

The enable/disable scenario is similar to the targeting pack shipping requirements. It might be reasonable to apply the same infra we have for targeting packs to the managed libraries.

The servicing infra for targeting packs is this:
https://github.com/dotnet/core-setup/blob/d59676539b88da3576c20e2150b09323f280c437/eng/Versions.props#L27-L44

If we ported over this disable logic to the managed projects, we could use the same logic:
https://github.com/dotnet/core-setup/blob/d59676539b88da3576c20e2150b09323f280c437/src/pkg/packaging-tools/packaging-tools.targets#L118-L152

This infra doesn't require you to remember to manually add/remove projects from a list. You just tweak the version once when you make the change to the library. Then, it builds in the current release, and automatically gets disabled once the patch version is incremented.