Thanks for your bug report. This is a known issue. You will find that % also has the same issue.

I have looked into this several times and there is commented out code that makes the core var/binvar routines reject single character % or & names. Unfortunately fixing this issue is not that clear cut.

There are hundreds of places in the code where commands/identifiers/features check if a string begins with % or &. In many cases, a stricter check for length is performed. In other cases, it is not. Changing all of these to strict/non-strict checks would affect different features in different ways.

For example, if a strict check is performed and & or % are treated as a non-valid names, some features will execute a completely different code path. Other features will return an empty string. And other features will report an error. These features were all implemented at different times, requested by different users with different demands, and updated at different times to handle new features, over the last 20+ years.

Basically, this cannot be implemented as a general fix without affecting backward compatibility. However, I might be able to make changes to some features where its clear that the code flow is not affected. But in general, it will be inconsistent. The solution, of course, is to not use single character % or & var/binvar names.

Quote
bug: //tokenize 32 &v | echo -a $regsubex(foo,abc,,,[ $1 ]) $bvar(&v,1-).text

The [] brackets need to be separate from all other characters in order for them to be parsed. Note that even if there was an issue with how [] are parsed, I will not change their behaviour in any way. This is some of the oldest code in the parser and it is far too brittle to be changed without causing backward compatibility issues.