Ну тут такая ситуация...
Существуют объективно как бы два разных типа данных: текст, и шматок бинарных данных.
Хотим мы, или нет -- но они немного разные.

Возьмем, скажем, чтение из файла DataToFile
У нас есть опция dtAnsiString, и есть dtPString. И не потому, что у нас такое извращенное мышление было при создании, а потому что берешь чужие файлы, и смотришь, как там данные представлены. Я смотрел еще более внимательно, и пользуюсь DataToFileEx, в котором префикс в dtPString может быть дополнительно 8-битным, 32-битным, и еще и с BigEndian. Ну жизнь так устроена - вижу такие файлы, и читать хочу...

И как то так получилось, что мы в HiAsm эти данные немножечко путаем между собой. Ну типа никого не предупреждаем - этот элемент обещает корректность только на "Тексте", А этот -- даже и на бинарных данных.

Как тут порядок навести, и что должно называться порядком - так сразу и не скажу. Думать надо.

В рамках конкретного элемента StrMask - декларируется корректность на "Тексте". Причем, так с самого начала и было (если учесть CaseSesitive)

Можно аналогичный сделать элемент типа StreamMask, в котором по определению не может быть св-ва CaseSensitive. Ну без проблем ведь... хоть и 4 аргумента у ф-ии.
Оно, правда, только на первый взгляд - без проблем А на второй -- начинаешь думать: а чего так просто? как какие-нибудь "#*?" в маску прописать? а почему тогда не полноценные регулярные выражения? а если регулярные выражения, то почему не генератор лексеров?
Поток идей и вопросов трудноостановимый может получиться.

Может проще все: есть простой, как сибирский валенок элемент -- зачем от него требовать, чтобы он прыгал выше головы...