@becker33 just informed me that we've been able to handle non-boolean variants since the cflags support was merged. Now that this is possible, I propose we start using them. Let's start with the MPI packages. For example, MVAPICH2 has the following variants that control the process manager:

    gforker         off       Sets gforker as one of the process managers
    hydra           off       Sets hydra as one of the process managers
    remshell        off       Sets remshell as one of the process managers
    slurm           off       Sets slurm as the only process manager

It also has the following variants for network type:

    mrail           off       Configures a build for OFA-IB-CH3
    nemesis         off       Configures a build for TCP/IP-Nemesis
    nemesisib       off       Configures a build for OFA-IB-Nemesis
    nemesisibtcp    off       Configures a build for both OFA-IB-Nemesis and TCP/IP-Nemesis
    psm             off       Configures a build for QLogic PSM-CH3
    sock            off       Configures a build for TCP/IP-CH3

Keep in mind that both of these sets are mutually exclusive (you can't use multiple process managers). By collapsing all of these variants into two non-boolean variants, we can remove a lot of mutual exclusion logic.

What would this look like? Instead of mvapich2@2.2b~debug~gforker+hydra~mrail~nemesis~nemesisib~nemesisibtcp+psm~remshell~slurm~sock, we would have mvapich2@2.2b~debug procman=hydra network=psm

@becker33 There are still a lot of things I don't understand or that may need to be added in terms of support. What would the variant initialization look like in a package.py? How can I specify a list of possible values for this non-boolean variant? I would like spack info to list each possible value as well.