Focusing on the "you have now N + 1 standards" problem, I think following the Language Server strategy is the way to go: you don't force people to support it, you focus on specifying an API that support a handful of representative bridges (let's say Python <-> Swift <-> Java <-> Haskell), with a builtin method to evolve and then let people realize that supporting this new ABI immediately brings support for every other language that supports it in an idiomatic-ish way.
Yes, the wrapper generators would not be built into the compiler, they're just little pieces of software that generate the relevant code (anyone could develop one in their own language in a couple of days).
The language exists merely as a way of directly interfacing with the ABI, a way to get the libraries out the door so interest in the ABI exists (same as how VSCode made LSP popular).
The problem with doing Python <-> Swift is that you cannot (and should not) try to expose the entirety of Python and Swift to either side. So you need an "extern ABI" solution to expose your Swift code, except this is not built in to the Swift compiler so now you are in trouble.
If you go the external route you end up with SWIG, which is something you only use when you have no other option (CVC4 moved away from it for example).
Having a language that directly supports the ABI sidesteps this issue. All code written in the language works with the ABI directly so you get the wrappers for free without thinking about how to implement them. A lot of libraries are written in C directly for this very reason!
Once it becomes popular enough, languages would implement "extern ABI" directly, and can now talk to each other over it without the middleman. Same as how a compiler with LSP support can be used in editors that are not VSCode.
