Paper 26.1.2: [rules] "then replace" reuses the first match's capture group ($1) for all matches in one message

[LoralonMC]

Are you using MySQL?

Yes

Are you using a proxy?

Yes - Velocity

"/version ChatControlRed" - plugin version

12.2.1

Optional: Error log

No response

ZIP of "/chc debug"

I emailed you the debug.zip

Steps to reproduce

Expected: A rule that matches multiple times in one message should expand $1 per match, so each match gets its own captured value (as Java's Matcher.replaceAll does).

What happened: Every match is replaced using the first match's capture value. The 2nd+ matches are still detected and replaced, but they receive the first match's $1 instead of their own. It looks like the replacement is resolved to a concrete string once (from the first match) and then applied to all matches.

Reproduce:

1. Add this rule to rules/chat.rs:
   match [(/[^\]]+)]
   then replace click:run_command:'$1'$1
2. Send in chat: hi [/spawn] bye [/back]

Result: Chat shows hi /spawn bye /spawn, and both links run /spawn.
Expected: hi /spawn bye /back, with the second link running /back.

Notes:

• The regex is correct — [^\]]+ cannot cross a ], so /spawn and /back are separate matches (verified by inspection).
• A message with a single [/cmd] works perfectly; the bug only appears with 2+ matches of the same rule in one message.
• Same result whether $1 is used inside run_command, in the visible text, or both.

Environment: Paper 26.1.2, Java 25, MiniMessage formatting.

[kangarko]

Confirmed and fixed for the next release. You nailed the diagnosis: the replacement was resolved into a concrete string from the first match and then stamped onto every match. The engine now expands $1-$9 and {matched_message} per match, so your rule produces a separate clickable link for each [/command]. Verified with your exact rule and "hi [/spawn] bye [/back]": the second link now runs /back.

One behavior note: group values are now taken from the message as displayed (after color stripping and similar rule preprocessing), which in edge cases is more accurate than before, not less.

[kangarko]

Fixed in 12.2.2. Your rule now makes a separate clickable link for every [/command] in the same message.