Steps to reproduce:
1. Create item with 9 captured groups in regexp and all 10 possible groups in "output template":

 log[/home/zabbix/test.log,(ABC)(DEF)(GHI)(JKL)(MNO)(PQR)(STU)(VWX)(YZ),,,,g1:\1 g2:\2 g3:\3 g4:\4 g5:\5 g6:\6 g7:\7 g8:\8 g9:\9 g0:\0]

2. Append to logfile a string: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Result is correct:

g1:ABC g2:DEF g3:GHI g4:JKL g5:MNO g6:PQR g7:STU g8:VWX g9:YZ g0:ABCDEFGHIJKLMNOPQRSTUVWXYZ

3. Reduce number of captured groups in regexp to 3, but leave all 10 groups in "output template" (do not restart agent):

log[/home/zabbix/test.log,(ABC)(DEF)(GHI),,,,g1:\1 g2:\2 g3:\3 g4:\4 g5:\5 g6:\6 g7:\7 g8:\8 g9:\9 g0:\0]

4. Append to logfile a string: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Result is incorrect:

g1:ABC g2:DEF g3:GHI g4:JKL g5:MNO g6:PQR g7:STU g8:VWX g9:YZ g0:ABCDEFGHI

Not-captured groups happen to contain their old values, although documentation https://www.zabbix.com/documentation/current/manual/config/items/itemtypes/zabbix_agent#supported_item_keys says that not-captured group is "an empty string if the N exceeds the number of captured groups".

This bug is not limited to log[] and logrt[] items. Similar results can be demonstrated with item preprocessing if output template references capture groups which do not exist in the regexp.