A paper[1] posted 7 days ago (!) gives an algorithm for SIMD decoding of
base64 while ignoring ASCII whitespace. This follows the ECMAScript 2026
standard[2] and WHATWG’s “living standard” [3].

This means that the performances issues with allowing at least ASCII
whitespace are somewhat mooted: the decoder algorithm in the paper
should be nearly as efficient as SIMD assuming completely valid Base64.

APIs for base64 decoding in other languages usually solve this by having
many different knobs to turn: for example, how to handle interstitial
padding bytes (for the purposes of concatenating base64 strings), if
padding bytes at the end are optional, what characters to ignore and
signal an error on[4], etc. This makes the API very convoluted, but has
the benefit that the same efficient decoder can be used for emails
(where base64 has whitespaces), raising an error on base64 with
whitespace, etc.

There are a few ways this SRFI can go:

1. It can simply remove the base64 procedures, in favor of external
libraries (or another SRFI) that defines a more advanced base64 API.
(This is my preferred option.)

2. It can keep the current strict-RFC decoder that rejects
non-alphabetic characters.

3. It can add whitespace skipping support such that it is a subset of
the ECMAScript 2026 behavior.

4. It can have an expanded base64 API to try and fit everyone’s needs.

Note that none of this applies to the “hex string” procedures, which are
effectively equivalent to FromHex[5] in ECMAScript 2026.

[1]: https://dl.acm.org/doi/10.1145/3859286
[2]: https://262.ecma-international.org/#sec-frombase64
[3]: https://infra.spec.whatwg.org/#forgiving-base64-encode
[4]: https://docs.python.org/3/library/base64.html#base64.b64decode
[5]: https://262.ecma-international.org/#sec-fromhex

-- Peter McGoron