I am parsing short options that involve either the option-value stuck together (e.g. -pVAL, -qVAL). I construct the two possible options in array pary, loop through them, storing the value in _vl.

I do think I can simplify the code

with the following

I can very-simply say that "I would never want to encounter your [incomprehensible ... although it obviously works ...] code" as your predecessor, after you had moved on to your next job. The very-primitive programming capabilities of the "bash" shell were, IMHO, never intended to be used for "real work."

It is for this very reason that the #!"shebang!" construct was invented. If you, for example, put #!/usr/bin/php as the very first line, then you can write the remainder of the script in PHP. The shell will silently transfer the remainder of the script to the specified language interpreter for processing, and the end-user will be none the wiser.

+1

It is time to switch to a different parser. Code is read many more times than it is written or modified and thus the return on investment for having readable code is very high. Conversely for the same reasons having code which is hard to understand has a very high cost which gets extracted repeatedly. Therefore priority needs to be on ease of reading for whoever comes next, even if it is just your future self.

Good old Perl remains ubiquitous and has been the go-to for scripting for decades, especially where string processing is involved. It was famous as the 'glue which holds the Internet together' and while it still has that role it is less famous. Python is another option.

(Edit: Getopt::Long is one relevant CPAN module)

I tend to use plain POSIX shell when possible, very rarely use Bashisms, and often use AWK when it suits the task. However, I mostly escalate directly to Perl when the shell scripting would get complex and the task is not suited to AWK.

tldr; choose the right tool for the job

additionally to post #2 and #3 [I can only repeat myself] why do you ask us if that code works for you?
Error messages should be sent to stderr, not stdout.
Incorrect command line arguments should stop the script execution. Also usually in such cases the usage is printed (just to know what went wrong and what would be the correct way....)

Yes, you can delete that if clause; it is redundant.
And it is even a bug fix: now the else branch can run.

Looks still a bit too complicated.
You use extended glob pattern and then ERE pattern...

Perhaps something like this (only extended globs, no loop)
or this variant (case-esac with logical OR)

The loop is needed because the contents of the pary is arbitrary rather than hardwired. The array denotes the set of possible user input formats.

For instance

I then want to match these with the actual user inputs (stored in arg)

What I do after is dependent on whether the user used the digit form (e.g "-p+([[:digit:]])") or the isolated predicate form (e.g. "-q").

How can I handle the aforementioned functionality in a clear and compact way?

...

I would say there is no simple way.
As far as I see dynamic parameter/argument specification is available for example in python, but I don't think you want to reimplement it in bash.
The way you can do it is to have a structure (which does not exist in bash). This will contain the regex to match the option, the parsing mechanism to "calculate" the value of that option, some kind of validation and also the variable which will store the result.
As far as I see your best possibility is to rewrite getopt (in c) to handle all the requirements you have.
By the way, you still need to validate those dynamic specifications, your bash script will crash in case of an incorrect regex.
I still don't know that specification, if you want to handle long options and short options, if you allow arguments without option, if you allow required and optional arguments, if some options have default values, if you allow multiple arguments for one option, if short options can be combined into one string, if the order of the arguments is important, if they can be repeated. Not to speak about the case when you want to generate a usage page.

The way is to go thru the arguments (one by one) - this is a simple while loop, try to identify them (this can be tricky, especially if you allow partial match for long options [--my_arg is accepted instead of --my_argument] and validate, process accordingly. I would try to split the input string into parts, like - or --, option name, value and do the processing based on that name.