Your regex matched the right shape in the wrong place

TLDR: [1] at the start of a line is a citation label. [0] in the middle of V_k[0] = C_k is an array subscript. Same characters, same regex, opposite meanings. If your pattern does not encode position, it will fire on the lookalike, and the lookalike is usually more common than the real thing.

The bug class

You are classifying text by pattern. The pattern is correct for the token you care about. It fires anyway on a token that shares its shape but not its role, because you matched the characters and skipped the context that makes those characters mean something.

This class is everywhere in text processing. 1. is a list marker at line start and a decimal in 0.5 amp. -- is a flag prefix in argv position and a range elsewhere. #foo is a comment or an anchor or a channel depending entirely on what precedes it.

The concrete instance

We built a detector that finds bibliography blocks in extracted documents. A bibliography entry opens one of two ways: with an author name, or with a numeric label.

const NUMERIC_OPENER = String.raw\[\d{1,3}\];
const ENTRY_START_RE = new RegExp(     String.raw(?:${NUMERIC_OPENER}\s*)|(?:${AUTHOR_OPENER}),     'g', );

The author half was already position-aware, anchored to a sentence boundary, because we knew prose says things like "as shown by Gao, J." mid-clause and that must not count as a new entry.

The numeric half was not anchored. We reasoned that [12] is unambiguous: nothing writes a bracketed number in the middle of a sentence.

Then a paper about power-flow modelling went through it, and page 3 came back classified as a bibliography. Page 3 is algebra. It contains the line:

the solution of (3) and (4) gives V_k[0] = C_k and I_SE[0] = D_SE

Two matches for \[\d{1,3}\]. Two matches is what our gate treated as self-evident bibliography, so the page was marked, and then a second paragraph on the same page got promoted along with it under the "this page is already a bibliography" rule. One false match cascaded into a false page.

Why the language produces it

A regex has no idea what a token is for. \[\d{1,3}\] is a complete and accurate description of the shape of a citation label, and shape is roughly half of the information.

The other half is position, and position is exactly what feels redundant while you are writing the pattern. You are thinking about the thing you want to match, and in your head it is already at the start of a line, because that is where you have been looking at it.

Zero-width assertions exist precisely for this, and they are the part people leave out because the pattern "works" on their test string.

The fix

Two additions. Anchor the numeric opener to the same sentence boundary the author opener already used, and require it to be followed by a name rather than an operator:

const ENTRY_START_RE = new RegExp(
    String.raw(?:^|(?<=[.)\]”"]\s)|(?<=[.)\]”"]\s\s)) +
    String.raw(?:(?:${NUMERIC_OPENER})\s+(?=[A-Z])|(?:${AUTHOR_OPENER})),
    'g',
);

The lookbehind says the label must open something. The lookahead (?=[A-Z]) says a label is followed by an author, never by =. Either one alone would have killed this bug; both together also kill the next one, where a label opens a line but the line is [0] = 0.

After the change, the same two documents produced reference regions on their five and two actual bibliography pages, and on no others.

Preventing the class

Three habits, in order of how much they pay:

Write the negative test first. Not "does this match [12] Smith, J." but "does this match x[0] = 1". Test strings that should not match are the ones that find this class, and they are the ones nobody writes.

Say the rule out loud in words, then check the regex has every clause. "A citation label is a bracketed number at the start of an entry that is followed by an author name." Three clauses. Our regex had one. The mismatch is visible the moment you write the sentence.

Prefer over-anchoring. A missed match usually degrades gracefully: the item stays in a less specific bucket. A false match reclassifies neighbours, and reclassification cascades. Given a choice, be too strict.

The lesson

A pattern that identifies a token by shape alone will fire wherever that shape appears, and in real text it appears mostly where you do not want it. The token you are looking for is a shape in a position. Encode both, or the more common lookalike will win.