Edit: The solution I ended up going with.

Constraints are a element in the Option XMLs and determine what options match a driver / printer combo. They like this:

'constraints' => [
			  {
				'printer' => 'printer/Lexmark-Z12',
				'sense' => 0
			  },
			  {
				'printer' => 'printer/Lexmark-Z31',
				'sense' => 0
			  },
			  {
				'printer' => 'printer/Lexmark-Z31',
				'sense' => 1
				'driver' = > 'lxm3200-tweeked'
			  }
			],

While they look simple I’ve run into a problem, how best to fit this into a data structure for easy lookup.

The printer and driver XMLs contain no references to options. Instead an option contains these constraints which specify which drivers and printer pairs apply to the option. Unfortunately generating a combo is driven based on the driver and printer data. Because of this we have to compute an in memory cache of these constraints in order to match a combo to its options (or reprocess the entire set of option xmls for each combo (which would be absurd (rather like these nested parenthesise( ( ))). The data structure of this cache is that has me troubled. I have a working structure, but I’m sure that if I was a better computer scientist I would have known something better than this:

'hpdj' => {
	'7' => {
	   'HP-DeskJet_540' => [
						   1,
						   'ev/137'
						 ],
	   '*' => [
				1,
				'ev/140'
			  ],

		 },
	'94' => {
		'*' => [
				 1,
				 '60'
			   ]
	  },
	},
'deskjet' => {
   '6' => {
		  '*' => [
				   1,
				   'ev/130'
				 ]
		},
   'GS-HalftoningAlgorithm-Gray' => {
		'*' => [
				 1,
				 'ev/GS-HalftoningAlgorithm-Gray-Standard'
			   ]
		}
	},
'printers' => {
	'HP-DeskJet_500' => {
			   '6' => {
				  '*' => [
						   1,
						   'ev/130'
						 ]
				},
		},
	},

So let it be said, even in a project as code monkey as processing XML computer science finds a way to sneek in.