The /help says the N parameter is referencing the Nth 60-character chunk, which also can include a 61st length-byte character if the encoding method is 'u'. For 'm' and 'u', it's equivalent to say that a chunk is the text encoding of the Nth chunk of 45 bytes from the input string, because of the 3-to-4 ratio encoding for those methods.

However Base32 'a' has a ratio of encoding 5-to-8, and this isn't compatible with assuming the output chunk is 60 characters. For Mime/UUencode, the length of input for 60 encoded characters is 60*(3/4)=45 bytes, but for Base32 it would be 60*(5/8)=37.5 bytes, and $decode can't decode correctly if a byte's bits are split across separate chunk strings. In this example, the $chr(255) in the 38th position has its bytes split half/half between chunks 1 and 2, and the 1-bits are not output into either chunk 1 or 2:

Code:
//var %n 1 | while (%n isnum 1-2) { bset -c &v 38 255 | noop $encode(&v,ba,%n) | var %text $bvar(&v,1-).text | noop $decode(&v,ba) | echo -a length $bvar(&v,0) $+(n=,%n,:)  $bvar(&v,1-) %text | inc %n }


If you alter the /bset string to have a 0 in the 39th position following the 255, $decode does fill 4 of the 8 1-bits into Chunk 2. If you move the 255 by editing the 38 to 33, the "P" and "6" being split across 2 chunks are the same encoded text chars appearing together in the new output, so the output isn't being garbled, it's just not possible for $decode to properly decode bits that aren't entirely present in the same input string.

Possible solutions:

1. The user needs to stitch 2 Base32 chunks together before trying to decode either.

2. Allow N to reference 45 input bytes for Base32 the way it references 45 input bytes for Mime and UUencode. This means Base32 needs the chunk size to be 72 not 60.

3. Allow the chunk size for Base32 to change from 60 to another multiple of 8 if 72 is too long.

4. If Base32's chunk size needs to remain 60, allow the N parameter to be also be a N1-N2 'range' value. This would allow $encode(&v,ba,1-2) to be a string that $decode can handle.

Even if #4 isn't chosen to fix the Base32 problem, this feature would also have a benefit for all 3 encoding methods, allowing someone to store a longer-than-4000 &binvar across several %variables or diskfile lines, without needing to encode dozens of times and stitch them together to have several 3600-char mime %variables or lines of a text file. i.e. $bvar(&longbinvar,bm,1-60) $bvar(&longbinvar,bm,61-120) etc.