2.1:  Footnote 3 is somewhat confusing, and not necessary.

2.1.1:  is somewhat confused.  The forward-reference to the fact that / is
optional is somewhat bewildering.

2.1.1:  Also, you have a missing word:  "regex because it [is] optional if"

Example 2.2:  Broken.  #1 and #2 don't match their annotations.

2.1.4  should either be renamed, or rolled into 2.2.2, or something.

2.2.2  "By backslashing a metacharacter, the regex matches the literal
character."  This has a dangling participle, and is confusing.

It can be dangerous to backslash an alpha character.  In Perl, as
opposed to vi, say, it is never dangerous to backslash a nonalphanumeric
character to get that literal character.  You mention an example of
this, but not the general rule.

2.2.3:  after "here are simple examples:", I was expecting to find
examples of how character classes are have different metacharacters,
since that's what's just been mentioned.  But that's not really what the
examples are about.

2.2.3.3:  The entire mention of the possibility of nested character
classes should be moved to the footnote.  And: is are nested character
classes a possibility?  what the hell would they mean?  Maybe give us a
URL here or a reference to somewher else in the book for further
information?

2.2.3.2:  mention of carets is perhaps a bit confusing, here.  Mightn't
it be better to leave character classes 'till the end?

2.2.4:  certainly case insensitivity should be left until way after
basic regex syntax is covered

2.3:  footnote 8 is particularly good

2.3.2:  another way to think of this is that the pattern will match the
first string it encouters that fits (well, except for greedy
repetition, which is kinda different anyway).

2.3.4:  It seems strange to call these "grouping parentheses", rather
than just parentheses, as the parentheses really dedicated to grouping
are "(?: ... )"

2.4.1:  Since you haven't introduced escape sequences such as \t and \n,
it's premature to include them here.

Also, the paragraph beginning "Perl can expand..." is particularly
confusing.  I have no idea what it means.  Are you conflating variable
interpolation and escape sequences?  Are they really all that similar?
(Heh.  I guess I do have an idea what that paragraph means.)

And why aren't \s and \b (for example) mentioned?

2.4.1.1:  "...but they don't get interpolated immediately" seems to
indicate they're very different.

2.4.1.2:  the last and second-to-last paragraphs say almost exactly the
same thing.

You should make consistent the use of the words "fail" and "succed".
You seem to be using the former to refer to the failure of a segement of
the regex, but the latter only to refer to the success of the regex as a
whole.

3.3:  It seems this should've been put with \n and \t and such, or
perhaps \n and \t and such should've been moved forward to be with this.

3.3.1:  It might be nice to mention that "word characters" are the
characters that are valid in variable names.

3.4:  the mnemonic that I've always thought of for \b is "word Boundary"

3.4.2 does not need to be its own section

3.4.4:  Ah, you use "word boundary" here.  Mention the phrase in table 3.4
then.

The paragraph beginning 'Using the string "what's up?!"...' is
confusing.  Maybe replace this and the next three paragraphs with a
table and a single paragraph?

3.5.3:  the second regex fails because Perl tries to match end of
*string*, followed by the sring 'str'.  You haven't yet introduced /$/
as matching end of line.

Ex. 3:  it would appear that /^.*?$/ should fit your criteria.  :-)
4.1.1:  why no mention of the slowdown that these variables impose?  If
it's premature to mention this here, perhaps refer the reader somewhere
else in the book?  Or make it a footnote?

I'm not quite sure I understand what "lazily evaluated" means.  Or,
rather, I think I do, but I see nothing that suggests that in the
documentation.  And what does it mean that "if you change the
string...[they] won't represent the text you originally used"?  Are you
saying that if I match, then evaluate $&, then change the original
string matched, that $& changes?

4.1.2:  is there any performance penalty associated with these arrays?

4.2.1:  eliminate mention of $DIGIT, which very much looks like it could
be a variable name produced by English.pm (even though it isn't).  At
the least, italicise "DIGIT" or make it not monospaced or something.
Maybe rename the section "Parentheses and $1, $2, $3, ..."

if you're going to mention that $1, etc. are read-only, why no mention
of this quality of $`, $&, and $'?

You meantion a performance plenalty here, referring back to the penalty
of the three previous scalars, but you never mentioned the performance
penalties associated with $', $&, and $'.

4.2.1.1:  very good that you mention this.  very very good.

4.2.1.2:  aren't there some delicious pitfalls to warn against, here?
Seems like there would be.

4.2.2:  probably this is where @- and @+ should be mentioned for
the first time, so you don't have to go back and explain the general
case.

4.2.5:  woah!  issues of the return value of m// should really be put
somewhere else.  This feels like a big jump

4.2.3:  which wins:  innermost, or last?  Maybe an example here is good.

4.3.1:  the issue of "what happens when you add a quantifier to
capturing parentheses" is adequately addressed in 4.2.1.1, and shouldn't
be repeated here.  Besides, it's out of place here.  Cut the second
paragraph short after '"match /pat/ ... each time".'

Example 4.4 is kinda cool.

4.3.2:  good pitfall.  but why isn't this in 4.2 somewhere?  It makes
more sense there, maybe after 4.2.1  4.3.2 really doesn't fit within
4.3 at all.

4.5:  using the fat comma in a split like this really looks to me like
data is going *into* $number, not out from number.

4.5.2:  "arguments to split()" should definitely come before "the
pattern", which is, of course, one of the arguments
5.1.3:  cool that you've included these alternative mnemonics

5.4:  this section probably needs to be completely reorganized

Footnote 5:  explain why HTML shouldn't be parsed with a regex, maybe
with a perlmonks link, maybe with a reference to `perldoc -q 'remove
HTML'`.  Let there be no doubt, here.  :-)

5.4.1.2:  (?: ... ) should have its own second-level section.  It's a
major issue (as is evidenced by the fact that it gets its own mention in
the introduction to the chapter).

Your mention of (?imsx-imsx:pattern) is way too short.  (It should have
all of 5.4.1.2.)  Also, your example is wrong.  It should be

        # [a-z] is case insensitive
        "ABC" =~ /[A-Z](?i:[a-z])[A-Z]/;

5.4.2:  this information is specific to the modifiers given in 5.4.1.1,
so the information should be there or in a sub-section.
6.1.4:  good caveat.

6.2.1:  the zero-width behavior is very interesting!  I don't think it
fits at all in 6.2, though.  It's general to m//g itself.  Perhaps it
would fit better between 6.1.4 and 6.1.5, as a second caveat?  Then the
pos() stuff should likely be obvious from that.  (Or possibly just
keep the first third of 6.2.1 much like it is, and move the rest.)

6.6.2:  Impressive example.  Maybe as an aside point the reader to
better ways of parsing, like Parse::Yapp and Parse::RecDescent?

7.3:  explain to me how keeping "a copy of the original string, and
[matching] against *that* string" is different from matching against the
current string?  (I assume it means that it never matches replacement
text.  Is this right?)

7.3.1:  a really cool example

7.4.1:  It seems that the heading to this could be eliminated entirely,
and the paragraphs above and below it merged.

7.4.2:  footnote 2 should be an annotation to the code.  Also, this
example is a bit confusing.

Also, since you give the specific `perldoc -q` command for the Perl FAQ
reference in 7.5, could you give it here?

7.5.1:  "hashes and substitutions" doesn't fit within the subject of
"telescoping substitutions"

7.5.3:  this doesn't fit, either

(both 7.5.1 and 7.5.3 have good info, they just don't fit in 7.5)

7.7:  Wow.  What an amazing example.  A bit hard to follow, though.
8.1:  you seem to have left out the second \b in the line

        s/\b(jeff)(rey)/[$1]$2/gi;

8.1.3:  this mention of "943" and "94" is wrong.  looks like it should be
"102" and "10", respectively.

8.1.6.1:  why is the alternation safer?  speed?

8.2.4.1:  when you say "one such example", it sounds like you're giving
an example of one of the "very specific cases", but you're not.

Exercise 8 seems very broken:  there is no example 8.3.4, and if you
mean the problem given in 8.1.7.5, the answer to the question is given
in 8.2.2.
9.1.1:  It's sorta confusing:  How can $`, $&, and $', for example, have
any meaning inside the regex?

You sorta explain one aspect of how $& works, but not the others.  But
what does it store, exactly?  The value of the text matched so far?
Does the value change as more text is matched?  What about backtracking?
What value can $' possibly have?

Answers to questions like these would be very very useful.

9.1.3:  the techniques aren't really explained, just shown in code.

9.2.2:  this is fairly unclear.  I have to stop and think about what
(??{ qr{...} }) even does.  Also, the linkage between "own set of regex
variables" and capturing parentheses is strange.  I figured you meant
that $& and friends would change each time.

9.2.3:  This practically begs a demonstration using recursive regexes
and code evaluation.  I see that you use just this technique at the end
of the chapter.  Say so, so I don't have to flip to the end of the
chapter to satisfy my curiousity!  :-)

9.3:  so, for ((cond) if|else), cond isn't a regex, but only one of
lookahead, lookbehind, code, or backreference?
10:  Your explanation of idioms is a bit strained.  :-)

10.2.2:  Perhaps reword as "Because NFA engines have more interest in
the regex than DFA engines,..."

10.2.3:  good description of a set of difficult matching problems.

10.2.3.3:  where's the illustration?  (I can sort of imagine what the
illustration would be, though.  The one in my imagination is good; keep
up the good work! ;-) )  Perhaps use this illustration method for the
previous examples?

10.3.2:  this section seems to fall flat.  I see what you're getting at,
but make it explicit, or something.

10.4:  does \G work in a similar way?  (I have a personal interest in
the answer to this one.)

10.4.3:  since you're talking about optimization here, not debugging,
don't make me go all the way through the debugging section to see how
floating strings impact optimization.