Conflict Between [#] Placeholder for Sequential Numbering and Filenames like "[#010]"

For reasons that I do not remember, I adopted, some time ago, a pattern for naming files that includes something like "[#010]" (used to indicate the sequential order of files).

Now I am trying to rename some of the files that follow that naming pattern, but, after some tests, it seems that the "[#]" placeholder used for sequential numbering conflicts with that scheme.

My intention is to replace the numbers inside the brackets by a new sequential number sequence and I have been trying to do that with the following rename preset: ABC - DEF 0101 [#010].orp (243 Bytes).

Please, try to reproduce the issue by downloading the preset, importing it and trying to rename the preset file (as its file name follows the pattern that displays the issue).

I know I could work around that limitation by doing two renames instead of one or using a script. Because of that, this is not a high priority issue, but, if my guess is correct, I think Opus would need a fix in that area to follow the "[#]" code specification more correctly.

The [#] code actually lets you specify the padding inline, e.g. [#3] means pad to 3 digits. In this instance, [#010] would be interpreted as pad to 10 digits.

A literal [#010] is not the issue.

A valid placeholder should be accepted by the RegExp \[#(\d+)\], but, my guess is that, the current code fails to match it when the target is nested like this [#[#010]].