You need the actual stack, I think, in the case of multiple types of openers without additional constraints, because if you just have raw counters you'd get tripped up by ([)] or similar.
So to generalise your point you need a counter for each transition to a different type of opener.
So (([])) needs only 2 counters, not 3.
You could constrain it further if certain types of openers are only valid in certain cases so you could exclude certain types of transitions.
EDIT:
([)] could indeed be handled by just additionally tracking the current open type. (([]]) is a better example, as it shows that to handle deeper nesting you need additional pieces of data that will grow at some rate (at most by the number of opens, possibly lower depending on which types can validly appear within which types)
Comments
You need the actual stack, I think, in the case of multiple types of openers without additional constraints, because if you just have raw counters you'd get tripped up by ([)] or similar.
So to generalise your point you need a counter for each transition to a different type of opener.
So (([])) needs only 2 counters, not 3.
You could constrain it further if certain types of openers are only valid in certain cases so you could exclude certain types of transitions.
EDIT:
([)] could indeed be handled by just additionally tracking the current open type. (([]]) is a better example, as it shows that to handle deeper nesting you need additional pieces of data that will grow at some rate (at most by the number of opens, possibly lower depending on which types can validly appear within which types)
maybe there's an encoding that can allow counting different ordered accumulations succintly.. (thinking out loud here)
ps: apparently there's already a lot of research on multidimensional dyck languages (somehow mentionned below)
https://arxiv.org/pdf/2307.16522
https://omelkonian.github.io/data/publications/d3.pdf