Lambda the Ultimate

I'd like some PL theory perspective on the idea outlined below, if you have relevant insight. Let me know if admin believes this is off-topic. But my interest is the PL angle, not the "let's write a cool app" angle. You can always hack away at getting a desired result without following any disciplined PL scheme, which isn't on-topic here.

As context, I want to start from a use-case, about processes interacting in a certain way. This is in contrast to how tech is sometimes discussed, first thinking of a neat formal idea, then trying to find a use. I want to start instead with a particular use and ask about any relevant neat formal ideas. My payoff is hearing ideas I would not have considered.

Instead of a boil-the-ocean scenario, where you pretend you can rewrite all software in a shiny new language, this use-case assumes things are not rewritten, that we operate in terms of whatever languages they use. So sometimes you talk to them in their own language, perhaps converting a new language to an old one at the boundary between new and old. Next is a concrete example scenario.

Suppose your new stuff goes in a new process that talks to others, like a browser and an IDE. If you have no UI frontend yourself, it looks like a daemon with one or more protocols to interact with other things. For example, a port serving http would let a browser interact easily with your process. This is especially easy because browsers are designed to work like that, but other standalone apps might also cooperate nicely, provided they have api to interact with other processes. I think this is true of emacs, to the extent you could use emacs as a frontend with a better IDE focus than a browser. Presumably other editors would also work as peers of your own process.

A browser likes Javascript, while emacs likes elisp, so presumably you would generate code to send them, if neither of those was a native focus in your process. (Altering a browser and/or an editor to understand your new paradigm is possible too, but it's interesting to work with existing tools that know nothing about you, and require no development changes at all.) Other tools will have their own preferred languages.

How do you go about doing that in a disciplined way with PL theory rigor? What PL concepts apply at different points and times? What general idea persists across different tools and languages? The new process speaking to each tool in its own language has some theory-of-mind about other tools, but that's not a PL concept as far as I know. Instead of winging each case in a one-off, specific, concrete way, what approach preserves some generality?

[I have little to add in discussion unless I think of questions about ideas suggested. It was recently suggested some things I say resemble a con artist's patter in some way, but I haven't been able to think of something I'm conning anyone about. I've had the same job for nine years, and it's boring. I don't look for a new job because web apps are not interesting to me, nor is commerce generally. I can't buff my reputation if I ignore social venues outside this one. I figure I'm pretty anonymous. I just crave interesting ideas. Coworkers want to talk about whether a local code style guide needs tuning; or if adventurous, they suggest rewriting tools in Erlang. So it's a creative desert. Being interested in PL topics is like being a Martian in places grinding away at the next incremental release.]

Edit: If you want code to run in a browser, you send it JS; if you want code to run in emacs, you send it elisp. (For some other executable, you send another language it wants.) The PL question is about being able to translate your model of code into another model, having a reason to believe qualities you want are present, and having something consistent in translation schemes.