I am still unsure if JWT can be encrypted. You find libraries encrypting it but then does it become JWE? Is it the same thing if the library still calls it a JWT? Are all of these just subtypes of JWTs or standalone RFCs?
It is all over the place. Makes me just take the route of creating a custom JSON payload and then encrypting or signing it.
They're all made of base64url-encodes segments, separated by a period. The first segment is always the header, and you can easily identify them by starting with "eyJh".
A plain JWT has two segments, the second is the payload. In practice AFAIK it's not really used because it's just bloating your data.
JWS has a third segment that's the signature of the payload plus private key, and can be verified if you have the public key. JWT.io is a site where you can play with these.
JWE has five segments including an encrypted symmetric key, the IV and ciphertext.
So yeah, JWE is technically a different subtype. I'll only note you can stick an already-encrypted payload in a plain JWT or a JWS, and you can also take a JWT or JWS and encrypt it, and none of these is the same as actual JWE token.
An example of such an approach is in the RFC appendix: https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2
Perhaps the biggest misconception about JOSE specs and JWT is that they are components, not a “batteries included” format. They are meant to be used to define further applications, such as ACMEv2.
Libraries often are written to solve specific problems (say, validating an OpenID Connect id_token) and blur the decisions such specifications made in profiling for their own use.
The nesting approach provides for non-repudiation of the decrypted JWT, which is important for federated identity use cases.
(Full disclosure, I've written one implementation: https://github.com/auth70/paseto-ts)