What are you talking about? The front-end can do exactly what the backend is doing in the current PEP 660 suggestion. It can make a .pth file or it can take the list of files and install symlinks or it can use the editables proxy mode to expose a proxy module. None of that needs to be done in the backend or re-implemented in every backend. The only difference between my proposal and PEP 660 in this regard is that in PEP 660 the front-end can’t make any of these choices because it doesn’t have enough information to do so.
Is this response separate from what I’m talking about? You are aware that backends are not long-lived processes, generally speaking? You’re suggesting that a library for building packages, rather than an application for installing and managing the installation of packages is the right thing to be installed as a system-wide, long-lived daemon? This does not seem like a good idea, considering that individual packages may rely on specific and possibly conflicting versions of their backends, so you may need many such backend daemons running.