Karthikeyan,

Thank you for taking the time to respond so thoroughly. In particular, in the future I'll be more careful to qualify and quantify potential performance improvements using `timeit` or `perf`.

That being said, as I mentioned the primary motivation for this is not a performance improvement - I just felt that was a nice potential side effect. Rather, this enhancement brings `base64.b16decode` into behavioral consistency with `binascii.unhexlify`. The `binascii` method already accepts both uppercase and lowercase hexadecimal characters by default.

However I can definitely understand what you and Serhiy are saying about this being a breaking change. Therefore I'd like to amend my proposal to the following:

1. Keep the `casefold` argument and corresponding logic, but keep the revised regex that will match against both uppercase and lowercase characters; and

2. Only put this change in for Python 3.8, this way existing code which uses the explicit argument on versions <= 3.7 does not break (but will still function normally).

I've altered this issue to reflect my amended proposal, targeting only version 3.8 and editing the type to be behavior instead of performance. In this way, the change will still make `base64.b16decode` consistent with `binascii.unhexlify` (and the case insensitivity of hexadecimal encoding more generally) without breaking existing code or requiring developers to change workflows using `casefold`.

Naturally there would be additional logic that *enforces* the case sensitivity if `casefold=false` is passed to the method, and this will likewise not break existing workflows either. 

If this change is considered agreeable, I will amend my open pull request to roll back the breaking change and refactor the way `casefold` is processed. From my perspective this amended proposal offers an upside in language consistency without any downside.