The approach you’ve suggested probably would’ve worked just fine in the pre-subscription days when only the big boys could afford source access and maintained their own forks of the engine, but it’s not very practical now that every man and his dog can be a UE4 developer. First of all, it’s a PITA for me as the language integration developer because I have to hack engine source to enable the new integration. I don’t have the rights to distribute engine source publicly, so I can’t put my code into a standalone public repository on GitHub. I’d have to maintain my own engine fork just for this, or publicly distribute just my code and a series of convoluted instructions that should be followed in order to enable my language integration, but both of those options are a PITA for me and the end user.
Remember that the end user may not be a programmer, and even if they are they may have little desire to maintain their own fork of the engine source just to enable my language integration. As it stands you can’t add a new language integration via the ScriptPlugin to the launcher build of the engine. IMHO language integrations should be standalone plugins, download one from the Marketplace, enable it on the Plugins window in UnrealEd, and you’re good to go, no stuffing around with preprocessor definitions, or replacing this or that source file and rebuilding the entire engine.
I agree that having more than one active script integration could be tricky, and it’s not a huge issue yet. However, I foresee a time when the Marketplace will contain useful assets that are written in Lua, Python, C#, etc., and I think all those assets should be interoperable… it’s not going to be terribly efficient in terms of performance but if you’re an Indie you can probably sacrifice some performance for all the time saved not rewriting these assets from scratch.