Sorry for the long title, but let's make it immediately clear: the keys used to sign transactions never leave the card and cannot be exported. You can however export any public key as well as the private key of keypaths defined in the EIP-1581 specifications. Those keys, by design, are not to be used for transactions but are instead usable for operations with lower security concerns where caching or storing the key outside the card might be beneficial from an UX point of view. Of course, exporting a key always requires user authentication.
Since 4.0 there is one export call, and it always takes a path. The second argument asks the card to make the exported path the current one, which is only meaningful on 3.x cards; pass false and your code works on both.
Exporting private keys is restricted to EIP-1581 paths:
For non EIP-1581 paths you can also export the extended public key, including the chain code. This allows, for non-hardened keys, to derive child public keys on the host.
Since 4.0 the master key cannot be exported in extended form. An extended master key lets the holder derive every non-hardened descendant of the wallet, so the card requires at least one level of hardened derivation below master.
A card holding a LEE seed exports its LEE key material through a separate call. See EXPORT LEE for the four components returned.
BIP-85 entropy is deterministic: the same seed and path always produce the same bytes, and any other BIP-85 tool can reproduce them. The path must live under m/83696968' with every component hardened.
exportCurrentKey(p2) sends no path, which on a 3.x card means "whatever path is currently active". A 4.0 card has no active path and ignores the parameter entirely, so the same call silently exports the master key instead. Always pass the path explicitly with exportKey(path, ...) — it behaves correctly on both generations.