It will be nice if eselect-php would support "embed" module (adding symlinks from /usr/lib(32|64)/php*/lib(32|64)/libphp*.so to /usr/lib(32|64)...
How do you plan to use this? All of the other eselect php... modules swap out the implementation behind fixed file names. The closest analogue is probably apache2, where we create a symlink for mod_php.so that points to a real shared object. With the embed SAPI, we could link e.g. /usr/lib64/libphp.so -> /usr/lib64/php7.3/lib64/libphp7.so which means that you never have to worry about the name of the library changing to libphp8.so (we had this same problem with php-5.x). On the other hand... this is a library. If there are upstream packages searching for libphp7.so (because that's what PHP upstream calls it), then it doesn't do us much good to rename it libphp.so, because nobody will know to look for it there.
I was thinking that we would have to use the name /usr/lib64/libphp7.so here, because you wouldn't want to switch out libphp7.so with an incompatible libphp8.so (all of your linked applications would break). That got me thinking: even though the soname doesn't change, is libphp7.so API/ABI compatible across releases of php-7.x? Answer: no. So, swapping out libphp7.so with incompatible versions (of libphp7.so) is going to cause breakage as well. And now I'm thinking that we shouldn't even try this until upstream promises a stable ABI for this SAPI. Do you have a use case where this would behave sanely in its current state?
I don't think this makes sense any longer but if you have a use case I haven't thought of, I'm still open to it.
