DavidH:
Option (a) for developers only (no fixes to tools and examples) requires addition of a device enumeration API, and a call to select one of the enumerated devices as active. The remainder of the SDK/API does not change. The assumption is that the active controller ID is by necessity stored not in the current app/process/thread, but in a system resource - you can't have more than one at a time per host, but you can "time slice" for calibration/comparison/testing.
Yeah, it's not very useful to a majority of developers. Option (a) is really not something anybody would choose to do unless the current software stack / firmware has that "one controller to rule them all" restriction built into every layer. In short, Option (a) isn't worth that much (but still better than nothing). You can prototype, you can't ship.
However, if the software stack can maintain the active controller per process or per thread already (e.g. as part of a "current context" and related API), Option (a) becomes (b). Shared memory IPC or multiple threads are not unreasonable requirements.
Best case scenario for Option (b), the developer can switch contexts each frame w/o prohibitive performance overhead. You could opt to extend (parts of) the existing API to take an explicit controller ID per-call, but that's more work for you and for developers. In either case, the developer would be able to obtain frames from 2+ controllers in a single threaded app, if so desired.
Handling both your Option 1 and 2 Use Cases - overlapping vs. adjacent FOV - could be left to the developer for now. I understand that you want to have the SDK combine "same space" captures into a single calibrated space, but I really don't think it necessary to put that Option 2 as a blocker in the critical path of releasing Option 1 access to API data for each controller separately. You can't really keep people from having two controllers looking at the same space anyway, whether or not the data processing they use was meant only for the case of fully disjunct FOVs.
I don't think it is crucial whether Option 2 will be available in the public or new SDK, as long as its release is not gated by the completion of Option 1 - these aren't really mutually exclusive, although most developers will certainly prefer, and switch to, the latter, once available. Exposing separately captured data from multiple controllers just looks like a much more predictable implementation/engineering task, compared to integrating the captures from multiple controllers into a single, integrated frame.
In short, I'd happily take Option (b) and 2, it will keep me gainfully busy until the full integration comes along.