It is the first I've heard of it too but according to this draft spec QR codes can't support binary:

https://datatracker.ietf.org/doc/draft-faltstrom-base45/

"Even in Byte mode a typical QR-code reader tries to interpret a byte sequence as an UTF-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode arbitrary binary data directly. Such data has to be converted into an appropriate text before that text could be encoded as a QR-code. Compared to already established Base64, Base32 and Base16 encoding schemes, that are described in RFC 4648 [RFC4648], the Base45 scheme described in this document offer a more compact QR-code encoding."

Here is the output alphabet:

   Value Encoding  Value Encoding  Value Encoding  Value Encoding
      00 0            12 C            24 O            36 Space
      01 1            13 D            25 P            37 $
      02 2            14 E            26 Q            38 %
      03 3            15 F            27 R            39 *
      04 4            16 G            28 S            40 +
      05 5            17 H            29 T            41 -
      06 6            18 I            30 U            42 .
      07 7            19 J            31 V            43 /
      08 8            20 K            32 W            44 :
      09 9            21 L            33 X
      10 A            22 M            34 Y
      11 B            23 N            35 Z

My initial thought is using "Space" as a valid encoded value seems like an enormous foot gun.

To trim or not to trim, that is the question

(2^16)^(1/3) < 41 So why base 45?

Yes, 41 characters would be sufficient.

I would have omitted these four (the asterix being there only to have a consecutive subset):

    36 Space
    37 $
    38 %
    39 *

Especially % can be confusing, as %20AA seems like a valid base45 both before and after urldecode. The $ is a lesser footgun.

I'd be keen to learn why they decided to use full 45 characters available in alphanumeric QR.

Because you encode using 45 different characters

The GP is saying 3 base41 characters can encode 2 bytes. Using base45 doesn't shorten the encoded message size unless they increase the encoding unit to more than 2 bytes.

Alphanumeric mode (which is 45 symbols: [A-Z0-9] and nine special symbols) is the only QR mode that's reliably supported among all scanner library implementations (latin1 is part of the extended mode, Unicode & raw binary get detected with implementation-dependent heuristics).

The encoding is great, actually: 4n bytes will get encoded into 6n alnums (base45 symbols) which are 3n * 11 = 33n QR-bits. A loss of just 3% (33/32 - 1). This works because [ alnum1 alnum2 ] by spec must get packed into [ 11 bits ] in the QR message bitstream.

Wrote an explanation here: https://news.ycombinator.com/item?id=27592936

Because the "binary" in QR codes (actually they call it "byte" mode) is supposed to be ISO-8859-1 per the ISO/IEC 18004:2005.

Which means it is a text mode, and actual scanners do treat it as text (although usually UTF-8 which goes against that standard, meh).

The document says that the encoding is 11 bits for two characters, which means that Base45 plus that encoding is very efficient, since 45^2 / 2^11 = 0.988, so only 1.2% of the capacity is wasted.