The reason it was the other way around though was because if OpenSSL came first (like it does in this PR) then include <openssl/ssl.h> could include a wolfSSL include with that name (depending on build order; if OpenSSL and wolfSSL include paths are both used) if I understand @elms' commit right.

I tend to think that if this combo isn't supported in all cases (which it isn't), we can hardly say it this is a supported combination. It also doesn't seem to be something much tested before. @elms commit says it adds wolfSSL support, but there's no mention of building in parallel with OpenSSL, so this was maybe something not tested or considered. To me the order picked seems to be the result of keeping changes at minimum while extending existing code. As for header confusion (picking the same header from the wrong project): if the header paths are setup correctly this should not happen because wolfSSL ones are referenced under wolfssl/openssl/.

(All of this is mostly guessing, my build attempts always failed with this combo.)

wolfSSL provides an OpenSSL API, that curl partially uses to do some things.

The only way we can build curl to use both OpenSSL and wolfSSL simultaneously is if they the two libraries do not share any symbols/function names, which would mean that wolfSSL's OpenSSL API would have to be disabled. That would then make the wolfSSL backend less feature rich.

If someone insists on making that work, fine, but I'm not going to personally lose any sleep over us not supporting that.

I plan to commit this as-is. This should help adding further fixes if someone is interested in doing them. It also brings .mk builds on par with cmake/autotools, which also don't explicitly block this combination.