Just my opinion, but: (a)The bug should be fixed and not worked around;

Both should be possible, that is, it should be possible to work around the bug until Outlaw provides an official fix. If variable PLII centre exraction were refactored to full extraction, with variable remixing (available regardless of source format), instead of variable extraction for PLII only, and fixed remixing (to accomodate varying number of speakers), a hack would be available for the end user. To boot, channel to speaker mapping just becomes another M (or M') transformation matrix.

Restricting variable mixing to those modes for which it "makes sense", i.e. as variable PLII extraction and making downmixing separate, makes the documentation more complicated, because one has to say, in effect, "in mode ... you can do ...; in mode ... you can do ... and ..., but not ...; in mode ... you can do ...", the assumption being that the reader can better understand a plethora of special cases instead of a series of orthogonal processing steps, even if some combination of those steps might not make sense.

Personally, I don't buy that line of reasoning. Outlaw could always offer a "novice" and "expert" mode with the "novice" mode disabling possible but likely not useful combinations.

It makes the underlying processing much simpler to code because it becomes an independet set of steps without needing "special cases" to forbid things that don't "make sense". Each step has it's own independent configuration settings, and only "novice" mode has the knowledge to gate "illegal" combinations of configuration settings.

It also could allow customers to define their own set of options for each step, allowing one to eliminate options that one does not use. Of course, always offer factory default "novice" and "expert" (and perhaps "maintenance" modes).

Because home theatre manufacturers and users are not interested in wanting to "experiment with front channel remixing". They just want to watch a movie, where dialogue comes from the screen and not in triple-mono from all three front speakers.

And that is optimized for a particular distribution of on-axis and off-axis listeners/viewers.

I'd like my pre/pro to have connections for seat sensors and remix appropriately depending on where the audience is sitting (the default being, well, as it stands).

While it might be outragous to suggest that Outlaw provide such functionality and hardware interfaces, the combination of the RS232 status and control port, and a dedicated microcontroller with seat sensors could do it if the 990 exposed a control mechanism for it's internal digital mixer. A separate analog mixer, controlled by the microcontroller would work too, but why on earth should I need that when there's a perfectly good digital mixer implementation likely present in the 990?

My overall point is that Outlaw should expose all the internal mixing and switching capabilities of the 990 even though its internal software limits how they are used to "keep it simple". Perhaps only via the RS-232 interface, so novices can't "mess things up by accident".

This opens up control of the unit to hackers, who might develop really useful control software models, some of which might eventually get folded back into internal software upgrades offered by Outlaw.

Win for hackers, win for Outlaw (who get free control software development), and win for future customers.