Sorry I know we're past review but I just saw this and I haven't seen many counter-points.
Similar to what @hishnash said, as an application developer in Swift I consider this a feature. In terms of source compatibility, in the 7 years now of managing a codebase with multiple hundreds of thousands of lines of Swift I cannot think of even 1 single time anyone on our team cared that we had to spend a couple days refactoring some code because something changed in either a dependency or in Swift itself. Usually these refactors are because there's an improvement, and that improvement garners excitement for that work even if it's tedious. Source compatibility from my "application developer" view is mostly a non-issue. Granted this also implies that changing retroactive conformances to using "module-qualifying" paths is also a non-issue.
But what will be an issue is if this becomes impossible to do in Swift without wrappers. I also use Rust in my work daily and there are plenty of things Swift can do I wish Rust could, and retroactive conformance is near the very top of the list. When there are crates that expose traits and then miss internal types which likely should conform to those traits I'm forced to make these wrapper types and pollute my code with them, they are incredibly annoying and noisy.
The ideal scenario imo is if a retroactive conformance does not yet exist then the user has a way to conform, if suddenly it does exist then the user is forced to cleanup their code, which correct me if I'm wrong but will happen as soon as the developer compiles anyway. Since some individuals in this forum wish to never have this capability / make it an error, then I think the proposal as written with a warning and an escape hatch is an ok compromise +1, though I do not wish this to be pushed any further at least for app development.
Edit: After reading the proposal a second time I noticed
Before the client removes their conformance and rebuilds, however, their application will exhibit undefined behavior
which I believe is referring to for example when a user upgrades their operating system and there's a new dynamically linked Foundation. Therefore I agree that this seems more applicable to dynamically linked libraries. Has the solution been considered where the library's conformance "wins" within the library if the conformance exists, but if it does not exist the user's wins in the library, and from their app outside the lib their own conformance wins? At least until recompilation. Also, in iOS world at least, if an app hasn't been compiled yet for a target OS doesn't the app operate in a compatibility mode of some sort for the older OS it was targeting, or is the intent here to give space to Apple to remove that mode?