Package source mapping cannot route version ranges of the same package ID to different feeds

Package source mapping in nuget.config binds package ID patterns to specific feeds, but the matching logic considers only the package identifier and ignores the version. This means a mapped feed can serve every version of a matched package ID, including pre-release builds, stable releases, and any future version published to that feed.

The goal is to separate internal pre-release builds from public stable releases for the same package ID by sending them to different feeds. Because the packageSourceMapping element has no version dimension, there is no supported way to express that boundary directly. Teams must either enumerate all package ID prefixes explicitly or add a broad * catch-all pattern, which removes the supply-chain guardrail by allowing any configured feed to serve any package ID.

The mapping also applies to the entire dependency graph, including transitive dependencies, so an unmapped package ID will block restore even when it is not referenced directly by the project. Older tooling before NuGet 5.7 ignores the section entirely.

Is there a supported configuration or extension point that adds version constraints to package source mapping? If not, what is the recommended design for splitting pre-release and stable feeds without a catch-all? How does the lack of version routing affect transitive dependency resolution when different feeds host different versions of the same package ID?