note
jettero
It would work if you used <c>$</c> instead. <c>\z</c> specifically asks for the end of the string and <c>.</c> won't match the <c>\n</c>s without a <c>/s</c> on the end. So <c>.*</c> and <c>\z</c> aren't adjacent in your first example — without the <c>/s</c>.
<p> It probably would work with <c>"\n"</c> because <c>.*</c> could match 0 chars. But in your example, it already matched several chars before the <c>\n</c> which it refuses to slurp, so it (meaning the DFA) can't get to the <c>\z</c> at the end.
<p> Of course, the more I think about it... you might argue that the <c>.*</c> should backtrack, skip over the <c>\n</c> and continue to match the 0 chars right before the <c>\z</c>. I believe <c>\z</c> has a special meaning though. It's not really matching characters. It's more of a border on things, like <c>\b</c>, so I suspect there really aren't 0 characters before it because it's not really there.
<p> UPDATE: I'm completely convinced this is a bug based on "[id://616551|id-616551]" below.
<!-- Node text goes above. Div tags should contain sig only -->
<div class="pmsig"><div class="pmsig-16186">
<p>-Paul</p>
</div></div>
616538
616541