> в нашей вселенной не нужно вообще искать конец null-terminated строки - именно для этого она null-terminated.

Все может быть. У вас там может и релок дешевый и хип не фрагментируется, так что при вставке или соединении длинной строки можно на каждый чих переаллоцировать. И целого вагона уязвимостей на почве "тут же должен был быть \0! Мы ждали!" у вас там наверное нет. И работать со строками можно не спеша, загружая каждый знак по отдельности. Хорошо вам там.

> Есть задача с этой строкой что-то сделать, и не уехать за ее
> край. И вот второе - со времен dec pdp11 - не требует никакой отдельной операции. Просто команда процессора сама перестает выполняться, доперебирав символы до этого нуля.

Познаково, ага.
Хочешь копировать или искать или еще что-то - можешь загружать за один заход 4-8-16 байтов (переход на 32-бита, появление MMX, SSE и т.д.), но будь любезен проверить все загруженные байтики на наличие 0.
Особенно доставляло  при необходимости выравнивания для чтения в (x)mm - если строка короче, то больше потратишь на высчитывание смещения и прочую подготовку. Особо неверующие и теоретики могут глянуть оптимированные варианты сишных операций со строками.

> а процессоры, поддерживающие паскалевские строки, у нас неизвестны.

У нас с незапамятных времен тот же штеуд умел.
Cтарые добрые repz, loopz.
Это если брать CISC c жирным микрокодом.

Еще, до сих пор работает
mov REG, [strlen]
...
dec REG/sub REG, 4 (8,16,42)
jnz/jnb mysuperloop / CMOVXXX REG, REG