Source precedence limits for package IDs absent from NuGet source mapping

When multiple package sources are listed in NuGet.Config, NuGet evaluates them in the order they appear unless a source mapping section redirects a specific package ID. For package IDs that are not covered by source mapping, changing the order of sources can cause a restore to select a different version of the same package if the feeds expose different versions. This creates a practical design question about determinism for teams that cannot enumerate every package ID in a mapping section.

The uncertainty is whether source mapping is the only supported mechanism to guarantee a fixed source for a given package ID, or whether NuGet applies additional precedence rules when mapping is incomplete. Without full coverage, a reordered NuGet.Config may introduce version drift across restores, but the exact boundary between supported behavior and unsupported configuration is not obvious from the documentation alone.

Is source mapping the only supported way to enforce per-package source precedence in NuGet, or are there other configuration options that override the default source order?

When a package ID is absent from source mapping and multiple sources contain different versions, does NuGet cache the previously selected source and version, or does it re-evaluate source order on every restore?

Are there documented limits on how source mapping patterns interact with the default source list for unmapped package IDs?