When to use \PassOptionsTo* and when \LoadClass/\RequirePackage?

Question

I've created a few packages/classes for my own purposes and learned (from, e.g., there) that \PassOptionsTo*[opt] is similar/equivalent to \LoadClass[opt], \RequirePackage[opt], or \usepackage[opt], respectively. In the context of the several option declaration mechanisms available, I wonder when to use which way of passing options? Are there, for example, obsoleted combinations to avoid or specific combinations with undesired side effects?

For example, I'm using sometimes

\DeclareStringOption{optA}
...
\DeclareOption{optB}{\PassOptionsToPackage{somethingRelToOptB}{pkg1}}

and then, for example,

\PassOptionsToPackage{key=\fam@optA}{pkg1}

or

\RequirePackage[keyA=\fam@optA]{pkg1}

I know that it might be a difficult question and nevertheless hope for a view takes on whether some variations are better than others.

Answer 1

One big difference between \PassOptionsToPackage{<options>}{<package>}\RequirePackage{<package>} compared to \RequirePackage[<options>]{<package>} is that the latter will throw an error if the package already got loaded with different options (provided the package doesn't use the new mechanism to resolve option clashes), whereas the former will silently do nothing (also assuming that it doesn't use the new option system). So there is a difference in behaviour that might be intended (say your class only works correctly if a package has been loaded with exactly those options).

Another thing to consider is whether you want to set a key-option of another package in any case and only expose an option to change the value, in that case a \RequirePackage[key=<foo>]{<package>} after your own option declarations is a viable solution, whereas if you want to specify a related option only if your option is used a \PassOptionsToPackage{<option>}{<package>} will most likely lead to simpler code than a later \if<opt-used> \RequirePackage[<related-opt>]{<package>}\else\RequirePackage{<package>}\fi.

Other than that there is no big difference, one could expect slightly different performance but that should be negligible.

---

As an aside, the following are a few pointers to this new system to resolve option clashes.

Currently there are two solutions (to my knowledge) that can resolve multiple loading attempts of a package (with clashing options). Both work by parsing the keys of each following call. This way you can act on them, but keys that have to be known during load time can't be resolved that way (and should be set up to throw an error in this case).

The first solution is the LaTeX kernel. The relevant features were added by the 2022-06-01 update. Documentation of the feature is spread across a few documents, relevant information can be found in ltnews35.pdf, and the "ltkeys.dtx" section of source2e.pdf. The relevant macros are \DeclareKeys (define new keys or change existing ones), \SetKeys (directly set keys to values, can be used for initial values), \ProcessKeyOptions (parses package/class options, also automatically sets up things for the handling of future options).

The second solution is the expkv-opt package (part of expkv-bundle, disclaimer: I'm the author) support for this was added in the in the 2023-01-23 release. The relevant macros are \ekvoProcessOptions (parses global options, options passed directly to the package/class, and all options of surplus attempts to load the package/class) \ekvoProcessFutureOptions (parses only options of surplus attempts to load the package/class), key definition can be done with either the basic interfaces \ekvdef and \ekvdefNoVal of the expkv base package, or with \ekvdefinekeys of the expkv-def extension package.