UTF-16, and non-BMP planes, were devised in 1996. The author seems to have been 5 years late to the party.
> The current permutation of Unicode gives a theoretical maximum of approximately 65,000 characters
No, UTF-16 enables a maximum of 2,097,152 characters (2^21).
> Clearly, 32 bits (4 octets) would have been more than adequate if they were a contiguous block. Indeed, "18 bits wide" (262,144 variations) would be enough to address the world’s characters if a contiguous block.
UTF-16 provides 21 bits, 3 more than the author wants.
Except they're not “in a contiguous block”:
> But two separate 16 bit blocks do not solve the problem at all.
The author doesn't explain why having multiple blocks is a problem. This works just fine, and has enabled Unicode to accommodate the hundreds of thousands of extra characters the author said it ought to.
Though maybe there's a hint in this later comment:
> One can easily formulate new standards using 4 octet blocks (ad infinitum) – but piggybacking them on top of Unicode 3.1 simply exacerbates the complexity of font mapping, as Unicode 3.1 has increased the complexity of UCS-2.
They would have preferred if backwards-compatibility had been broken and everyone switched to a new format that's like UTF-32/UCS-4, but not called Unicode, I guess?
> The current permutation of Unicode gives a theoretical maximum of approximately 65,000 characters
No, UTF-16 enables a maximum of 2,097,152 characters (2^21).
> Clearly, 32 bits (4 octets) would have been more than adequate if they were a contiguous block. Indeed, "18 bits wide" (262,144 variations) would be enough to address the world’s characters if a contiguous block.
UTF-16 provides 21 bits, 3 more than the author wants.
Except they're not “in a contiguous block”:
> But two separate 16 bit blocks do not solve the problem at all.
The author doesn't explain why having multiple blocks is a problem. This works just fine, and has enabled Unicode to accommodate the hundreds of thousands of extra characters the author said it ought to.
Though maybe there's a hint in this later comment:
> One can easily formulate new standards using 4 octet blocks (ad infinitum) – but piggybacking them on top of Unicode 3.1 simply exacerbates the complexity of font mapping, as Unicode 3.1 has increased the complexity of UCS-2.
They would have preferred if backwards-compatibility had been broken and everyone switched to a new format that's like UTF-32/UCS-4, but not called Unicode, I guess?