While this is certainly useful, I don’t see it as more achievable. We have to either distinguish different versions by file name (diverged from other platforms) or let the executable inject DLL path first (hard unless we use a custom import library IMO). A low-cost solution of this is to use an xcrun-like tool to shim and inject the paths, which I believe still need broad discussion and investigations.
ABI stability on Windows is definitely not a short-term goal, but it should be something on the roadmap. Unlike Linux, which doesn’t guarantee a stable ABI, I believe the post implies that MSVC will keep ABI stable in no less than 2 years, before the next Visual Studio release (likely 2025) comes out. By the time it should cover all the supported Windows versions, including LTSC. It is also very likely that the story will continue ever since, making a natural ground for Swift ABI stability to fit in.
Let’s look back in 2019, when @jrose wrote ABI Stability and More:
As development of Swift on Linux, Windows, and other platforms matures, the Swift Core Team will evaluate stabilizing the ABI on those platforms.
And @tkremenek spoke of ABI on Linux on the forums:
Finalizing the ABI on Linux is less valuable in the server domain (one of the most active use cases for Swift on Linux) than the (say) iOS app domain since service executables are routinely built from source for deployment in that domain anyway.
The Windows story is more like Darwin than Linux. It is client-dominated. Binary and even commercial libraries are common. It has a full and stable set of system APIs. All these make ABI stability on Windows more promising and valuable.