Should libexec_weston be promoted into a proper public library?

Currently, libexec_weston is a private shared convenience library that contains essentially everything that makes the weston binary, and is installed without a pkg-config file into an unconventional library path to avoid other projects linking to it. It is unversioned and has no stable ABI. You cannot install multiple versions of it simultaneously, like you can't install multiple versions of Weston the compositor.

Libexec_weston exists for two reasons:

• Weston plugins can be built with all symbols resolved when they link to it. (Libweston plugins do not need or use it.)
• Weston test suite uses it to run the compositor in-process.

Other projects cannot currently do either. Would other projects be interested in having those possibilities?

If we were to promote libexec_weston as a proper public library:

• It needs to be versioned. That means it has it's own major version number separate from libweston.
• It needs to have a defined ABI, so that we know when we break it and need to bump the major version.
• It probably needs a better name. libweston-frontend maybe?
• It needs a pkg-config file.

It would also cause questions and issues:

• Does it need to be parallel-installable like libweston is? What to do with the installed file resources it needs?
• It would be a library that does process-wide actions, e.g. sets up signal handlers.
• Do we keep the project version derived from libweston major version and let libweston-frontend major version diverge? What happens to the project version when libweston-frontend bumps major but libweston does not?

The version number questions would have applied to libweston-desktop as well if it wasn't decided to strictly follow libweston major both ways. Doing that with yet another library may be going too far.

Should we go for this? If yes, why?