I prefer a correct solution that contains some repetition to an incorrect solution any time. There are ways to make .*? work correctly, but they include a certain amount of backtracking control, which makes them harder to maintain.

This is true especially if Z happens not to be just a latter, but a more complicated pattern.

If that's the case, you should use interpolation anyway, and [^Z]+ is to be replaced by (?s:(?!$Z).)+

In general it does make a difference if Z is actually a single character or something else, and if it's something else that should be mentioned in the original question anyway.

Update: added missing quantifier

I prefer a correct solution that contains some repetition to an incorrect solution any time. There are ways to make .*? work correctly, but ...

I agree that an incorrect solution doesn't make sense, but is it incorrect? .*?Zwould match the shortest possible sequence of characters up to, but not including, the letter Z. Could you give an example where this would fail?
-- 
Ronald Fischer <ynnor@mm.st>

I haven't really thought about whether the solutions with .*? are actually incorrect, but most of them will almost certainly go wrong if you extend the regex latern on with something that might force backtracking on the preceeding construct.

Example:

$ perl -wE 'say "yes" if "A BCZD ZA"  =~ /^A(\s.*?)?ZA/'
yes
[download]

Here I added an A to the end, which causes backtracking when there's no A after the first Z. Which in turn allows a match that was forbidden by your rules.

(Update: This is a general problem when translating "may not occur inbetween" to "minimum match": it's only the same under certain very fixed conditions. You can "rescue" such a solution by putting it in (?>...) non-backtracking groups, but I still recommend against it).

So maybe your example wasn't actually wrong (and I apologize for having called it so without any proof), but it's surely not very maintainable, because a very simple, innocent change can break it.

This is true especially if Z happens not to be just a latter, [sic] but a more complicated pattern.

To expand on moritz's Re^5: This regexp made simpler: This, I think, is exactly the motivation behind regex objects. Using really non greedy match as an example, some regex objects can be factored out and treated as if they were atomic – because they are, more or less! (The big gotcha is that things get tricky if the factored regexes contain capturing groups, which consequently should be avoided. This problem is ameliorated by 5.10's relativistic approach to referencing capture variables.) The 'regex factoring' approach can lead to a lot more initial verbosity, but this cost is repaid many-fold by greater ease in conceptualizing, building and maintaining complex regexes.

In the example below,  $not_S* and  $not_S*? work as one would expect for  .* and  .*? expressions. (There is a problem with the counting quantifiers {n} et al: something like  $not_S{3} looks like a hash element; the more awkward  (?:$not_S){3} must be used instead.)^{[See update]} Note that something like  $S or  $E could be a much more complicated (and factored) pattern.

>perl -wMstrict -le
"$_ =
 'no a START no b START yes c END maybe d END no e START yes f END';
 my $S     = qr{ START     }xms;
 my $E     = qr{ END       }xms;
 my $not_S = qr{ (?! $S) . }xms;
 my $Lazy  = qr{ $S $not_S*? $E }xms;
 print qq{'$_'};
 print 'greedy:   ', map qq{'$_' }, m{ $S $not_S*  $E }xmsg;
 print 'lazy:     ', map qq{'$_' }, m{ $S $not_S*? $E }xmsg;
 print 'compound: ', map qq{'$_' }, m{ $Lazy }xmsg;
"
'no a START no b START yes c END maybe d END no e START yes f END'
greedy:   'START yes c END maybe d END' 'START yes f END'
lazy:     'START yes c END' 'START yes f END'
compound: 'START yes c END' 'START yes f END'
[download]

Update: Somehow I had the idea that  $scalar{3} in a regex would interpolate like a hash element, but I just tested this in 5.10 and AS 5.8.9 and 'taint so. Where did I get this notion? Update: Ah,  $scalar{'7'} and  $scalar{$n} interpolate like hash elements and  (?:$scalar){$n} looks like a quantifier again; problem solved.