If someone is trying to use both the ApiVersioning feature and the ExceptionHandler configuration that uses a path name, you will get an ambiguous routing exception on every error because the router uses the selected routes in the IApiVersioningFeature from the original request which contains the original route.

Here is the routing code from ApiVersioning:
https://github.com/microsoft/aspnet-api-versioning/blob/e16b579d240574053ebd8e7ee38c8686beaee174/src/Microsoft.AspNetCore.Mvc.Versioning/Versioning/ApiVersionActionSelector.cs#L165

It seems like the ApiVersioning code lives in a separate repo not under the dotnet umbrella which introduces a dependency problem. I wonder if its possible to introduce an extension point for this middleware that allows implementers to add additional functionality to the ClearHttpContext step of the exception middleware. This way, the ApiVersioning folks could add an implementation which clears their feature.

Bottom line, the exception middleware is already clearing the IRouteValuesFeature in order to accomplish its goal because it is assuming that this is the only code that was involved in selecting the original route. However, any libraries which introduce a custom layer of routing, like ApiVersioning, will fail to be cleared properly before re-entering the pipeline. Adding some kind of extension point such that routing libraries can expose the means for others to clear their state, could clear this issue up.