Since 'v' is still in beta, the opportunity is available to change the design, if desired, without affecting backwards compatibility.
While $decode had 3 different ways of handling invalid characters in the input for the u/m/a encoding methods, the 'v' method has a 4th method - treating invalid characters the same as if they were the 1st character of the encoding alphabet '0'
I believe $decode should handle invalid 'v' strings the same way it handles them in the 'a' input, halting with an error.
* *
1. For 'v' Z85, the decoded result is the same as if invalid characters were first replaced by the 1st character of the encoding alphabet, '0'
//bset -t &v 1 ~abcde"',;\_`|~fghij | echo -a $decode(&v,bv) -> $bvar(&v,1-) -> $encode(&v,bv) : $bvar(&v,1-).text | echo -a result: 0abcde000000000fghij
2. For 'u' UUencode, an invalid character in the input causes $decode to return $null without any halting error.
//var -s %a ,>'EZ9F]O8F%R>'EZ```` | echo -a : $decode(%a,u) | echo 4 -a null: $decode($lower(%a),u)
3. For 'm' base64, the input is truncated at the position where an invalid character is found, and any following text is ignored.
//bset -t &v 1 abcd@efgh | echo -a $decode(&v,bm) -> $bvar(&v,1-) -> $encode(&v,bm) : $bvar(&v,1-).text | echo -a 2nd echo
4. For 'a' base32, an invalid character in the input triggers an error which halts the script.
//bset -t &v 1 abcd@efgh | echo -a $decode(&v,ba) -> $bvar(&v,1-) -> $encode(&v,ba) : $bvar(&v,1-).text | echo -a 2nd echo not seen
* *
As far as how 'm' invalid input should be handled, it should probably be doing the same as 'a' also, but it's your option as to which of several backwards compatible behavior is retained. For the #3 example, the $decode result in various versions was:
6.35-7.29 abcdefgh (invalids pruned from input before decoding entire string)
7.38-7.41 abcdAfgh (current 'v' behavior except with it's own 1st char of encoding alphabet)
7.42-7.52 $null without error (same as current 'u')
7.53-7.72 abcd
