Remotely related observation: The sections in a BAR-file like
XnView/default.bar begin with a
count=n line followed by
button1=0 or similar up to
button57=56 for the last pre-defined action 56
Delete. I determined the pre-defined actions by trial and error up to
count=60 with
button60=-1, where -1 indicates
undefined with a vertical bar to separate button groups, so if you'd really want 60 buttons it would require a
cmd60=cmd_… for some action known by name
cmd_….
In other words, what you want
could be implemented as
count=n in the
[Rename] section of a future XnView version, but I'm not sure if that's a good idea. For my own purposes I rarely or never need old rename-patterns, let alone 20 old patterns. I often use the other old rename-options (start, step, extension, etc.), e.g., start at 01, step +4 up to max. 97, and then I can insert max. 3+3 crops or other modifications below and above the original 01, 05, 09, etc. up to 97.
If you have more than 20 rename-patterns you want to preserve maybe that should be solved completely differently, e.g., stored as XBS-files in the folder for XnView Batch conversion Scripts, or support a new XRP (XnView Rename Pattern) file extension for this purpose.
What you already could do are different XnView1.ini, XnView2.ini, ... each with its own set of 20 rename patterns, but you'd need a script to keep everything else in this INI-zoo identical, and each INI would need its own LNK-shortcut (with the corresponding inifile option), so I guess that's a clear case of making it worse.
