Regarding the question of packages using the same option names, there is no problem in that instance. If you're using xkeyval package, you only need to be cautious with your use of \ProcessOptionsX*, especially in a class file. See page 19 of the documentation for the xkeyval package for an example. Here is a quote from there:
The use of \ProcessOptionsX* in a class file might be tricky since
the class could also be used as a basis for another package or class
using \LoadClass. In that case, depending on the options system of
the document class, the behavior of the class loaded with \LoadClass
could change compared to the situation when it is loaded by
\documentclass. But, since it is technically possible to create two
classes that cooperate, the xkeyval package allows for the usage of
\ProcessOptionsX* in class files.
Notice that using LaTeX's \ProcessOptions or \ProcessOptions*, a
class file cannot copy document class options. In case you want to
verify whether your class is loaded with \documentclass or
\LoadClass, you can use the \XKV@documentclass macro, which
contains the current document class.
There are many key-value parsers (see the list at a big list of key-value packages). Below I make some comments on some of them.
xkeyval
In the case of the xkeyval package, you may want to note the following:
The xkeyval package has many interesting features, such as the use of pointers, presetting and post-setting keys, family filtering, and setting rm (remaining keys) as many times as you may wish. It is also efficient in computational resource utilization. To define and set a key, its runtime is much shorter than that of pgfkeys, and it defines far fewer macros than pgfkeys.
But, like every package, it has some shortcomings (if that is an appropriate word to use here). Some of its drawbacks include:
It can't be loaded before \documentclass, but you can load keyreader package before \documentclass. The keyreader package redefines some internals of xkeyval and provides a frontend to xkeyval.
This one isn't a serious drawback, but the xkeyval package can't accept default values with parameter characters. Perhaps David Carlisle's original idea of a key-value system excluded the need for this feature. For example, the following (A) fails.
It strips up to three levels of outer braces in key values. If preserving braces is important to you, then you need to pad your key values with additional braces.
Its stack management system leaves room for improvement. To allow \setkeys to be infinitely re-entrant (Oberdiek test), it saves the current "state vector" of \setkeys before calling \setkeys. The way this is done by xkeyval is not efficient: iterations to build the stack are done twice (one for pushing and one for popping the stack) for each call to \setkeys. The keyreader package uses only one iteration both for going down and coming up the stack.
The macro \CurrentOption was missing from the state vector of xkeyval's \setkeys. This may cause problems when \setkeys is nested. I have had an unpleasant experience in this regard. Version v2.6b (2012/10/14) of the package corrected this omission.
Unlike pgfkeys, the xkeyval package has no provision for (a) expanding the value of a key at setting keys, (b) updating the callback of an existing key at runtime, (c) style/observer keys, (d) multi-parameter callbacks, (e) family filtering -- although it has key filtering via rm keys. These features are provided by version 1.1 (2012/08/01) of the skeyval package.
Its selective sanitization scheme of Uwe Kern, which it deploys to cope with babel, leaves room for improvement. It's more expensive than search-replace sanitization schemes.
The development of xkeyval has ceased since 2008. Version v2.6b (2012/10/14) corrected a few bugs but provided no new features.
Code (A):
\define@key[KV]{fam}{key1}[\def\x##1{*##1*}]{}
\setkeys[KV]{fam}{key1}
Code (B):
\setkeys[KV]{fam}{key2=\dimexpr\usevalue{key1}*5\relax}
pgfkeys
In the case of the pgfkeys package, you may want to note the following:
The handler system of pgfkeys is a great attraction, but you need some experience to use it effectively. Because of this feature and the pgf/tikz graphics bundle, pgfkeys is popular, despite its relatively higher computational overhead.
If babel is loaded with certain options, key parsing by pgfkeys may fail, unless you load pgfkeyx package.
pgfkeys package on its own doesn't process package or class options. For options processing, you need pgfopts package.
This one is a personal opinion. I find key and family filtering less convenient to manipulate using pgfkeys than with xkeyval and skeyval packages. It will be interesting to have pgfkeys' handler mechanism implemented for xkeyval package or a supported package with a similar syntax. This is attempted by version 1.1 (2012/08/01) of the skeyval package. With the skeyval package, you filter out a key, family or path by simply calling the .ignore handler. For example,
\directkeys{
% Start off on two separate paths:
.paths = {KV1/fam1,KV2/fam2},
.initialize keys after define,
.define keys = {
.exec code = \def\iden#1{#1},
% Define 1 ordinary key. Only the keyname field is mandatory, but
% we have filled all the fields here:
.ord/key1/default1/\def\codeA##1{#1*##1},
% Define 2 choice keys with the same attributes. Choice keys can have
% default value, state pattern or binding set, code for valid value, and
% code for illegal value. Only the keyname field is mandatory.
.choice/{key2,key3}/justified/{
center.do=\def\curralign##1{\hfil##1\hfil},
right.do=\def\curralign##1{\hfill##1},
left.do=\def\curralign##1{##1\hfill},
justified.do=\let\curralign\iden
}/\def\codeB##1{#1**##1}/
\let\curralign\iden
\typeout{Value of key `\skvcurrentkey' is invalid; `justified' assumed}
,
% The starred (*) form of choice key will always use the lowercase of the
% user input to match the singleton:
.choice*/key4/{A/X}/{
A/X.do=\def\currcolor{blue},
A/Y.do=\def\currcolor{green},
B/X.do=\def\currcolor{red},
B/Y.do=\def\currcolor{magenta}
}/\def\val{Value of key4: #1}
},
.exec code = \def\acenter{center},
% In Java speak, keya and keyb are subjects of the observer key1.
% The observer can subscribe to attributes of the subject. In the
% following example, the observer (key1) asks to be notified of the value
% of the subject:
.style = {keya,keyb}/key1=#1,
% Don't set key1 and key2 on path KV1/fam1:
.ignore path = KV1/fam1,
% Ignore key3 and key4 on all active paths:
.ignore keys = {key3,key4},
.set keys = {
% Check the logfile for a warning about the invalid value of key2:
key1=value1, key2=value2, key3=.expand once{\acenter}
},
.restore keys = {key3,key4},
.restore path = KV1/fam1
}
