[This topic has been discussed to some extent already at various other occasions such as PR #4992.
It is certainly not something to be tackled before the 3.0 release; I just file this as an issue in order to keep track.]

The OpenSSL code has essentially a three-level structure with a stack of two libraries and a command-line application at the top:

• openssl apps
• libssl
• libcrypto + engines/providers

where the apps/ directory contains various potentially generally useful code for handling crypto-related files and messages, HTTP and TLS client/server and CA functionality, support for higher-level protocols like S/MIME, CRL fetching, OCSP, CMP, and certainly more to come. Meanwhile there is some form of internal library for that code in apps/lib/.

While this code serves as a model for using the crypto and ssl libraries and can be used in a limited way by invoking the openssl application(s) at CLI level, it cannot be re-used directly. Other applications that need similar functionality need to copy and generalize or re-implement portions of that code and then maintain it.

On the other hand, for historical reasons the crypto library contains some code that is actually too high-level there, for instance the HTTP client and OCSP and CMP client and server application logic (while low-level code such as OCSP and CMP ASN.1 structure handling likely needs to be done within the crypto lib since they make use of internal functions).

So it would be very helpful to introduce a further level in the hierarchy containing a more application-oriented library:

• openssl apps and external OpenSSL-based applications
• libsec <-- new (with tentative name)
• libssl
• libcrypto + engines/providers

Then all more high-level and application support functionality can go there. This would make much of the generally useful code that so far resides in apps/ directly accessible to other applications at the programming level, i.e., in the form of a library/API, with all the re-usability advantages that this brings. It would also relieve libcrypto from more high-level (non-crypto) topics.
This library would also form an ideal condensation point for further higher-level uses of crypto and TLS that may in the future get integrated with OpenSSL.

Of course, implementing this would be a major effort because
it would require lots of re-structuring but also API design, implementation, and maintenance.
On the other had, it should bring an enormous boost on the programming-level usability of OpenSSL.