in reply to repeated regex capture

The “c” modifier can also be useful in cases like this.   From perldoc perlretut:   (Not the first place you’d probably look to find it...)

The final two modifiers "//g" and "//c" concern multiple matches. The modifier "//g" stands for global matching and allows the matching operator to match within a string as many times as possible. In scalar context, successive invocations against a string will have ‘"//g" jump from match to match, keeping track of position in the string as it goes along. You can get or set the position with the "pos()" function.
...
A failed match or changing the target string resets the position. If you don’t want the position reset after failure to match, add the "//c", as in "/regexp/gc". The current position in the string is associated with the string, not the regexp. This means that different strings have different positions and their respective positions can be set or read independently.

The bottom line is that these modifiers allow you to “walk through” a string.   One thing that you need to be very mindful of, however, is that you must specify undef, not zero, to reset the position.   From perldoc -f pos:

Returns the offset of where the last "m//g" search left off for the variable in question ($_ is used when the variable is not specified). Note that 0 is a valid match offset. "undef" indicates that the search position is reset (usually due to match failure, but can also be because no match has yet been performed on the scalar). "pos" directly accesses the location used by the regexp engine to store the offset, so assigning to "pos" will change that offset, and so will also influence the "\G" zero‐width assertion in regular expressions. Because a failed "m//gc" match doesn’t reset the offset, the return from "pos" won’t change either in this case.

(I belabor this point, hoping sincerely that I do not offend anyone by doing so, because there is a rather large lump on my forehead (and an equal-sized dent in the wall) from not carefully reading the boldfaced text!   Incorrectly setting the position to zero, not undef, was a nass-s-s-s-s-s-ty bug that escaped detection for a long time.)