In general, I recommend that you first gather-up all of the options that were specified, in some reasonable data structure.   (I see no particular merit in “fancy-pants” representations such as bit-fields.   Do not become mired in such concerns ...)   As long as, at the end of the day, you have captured what the user specified ... and have detected errors such as specifying a parameter more than once when you’re not supposed to ... then “anything that works is quite good enough.”

The easiest error-case is a tpyo.   Dispose of it summarily.

Moving on, you should look for request contradictions, omissions, and inconsistencies, starting with the most serious one.   These are combinations of options that, although they are syntactically-valid uses of those options, add-up to a request that is erroneous because it cannot possibly be interpreted.

The third step should be looking for requests that will call for more user hand-holding, because, the at this point user has made a superficially-legitimate request.   Now, you are looking out for requests that, while they may make syntactic sense, do not make sense.   This requires a more carefully-constructed error message which guides the user in the right direction.   At this point, you know that you are dealing with a user who genuinely knows what he wanted to do, but who did not succeed in knowing how to tell your program to get the job done.   At this point, you need to provide the user with the most-informtive guidance that you can come up with.

And, if you actually get to this paragraph, “do what they say!”