We have to make a decision -- what functionality is fundamental to a given channel. We could load every channel up with tons of features no one is ever going to use. Take the embedded Stop signal of the High Speed Stream. I get close-but-not-quite-as-good performance with the HS Stream as compared to the raw queue refnums. The loss is almost entirely in the small amount of data movement needed to track the stop signal. That embedded stop is something I see in so many apps that it seems worth the overhead.
One of the keys of the channel design is that we don't want NI to be the ones defining all of the channels. We are NOT productizing this aspect of channels this release because there are some instabilities around it, but you CAN write your own channel templates and have them appear in the channel dialog. That allows you to create new channels that have additional capabilities.
The one thing I think we do need to add is a priority queue. We have a lot of requests for that. This is not the "enqueue at opposite end" ... that gets abused WAY too much. This is creating an actual priority queue protocol so that high priority enqueues can go through and still themselves be handled in FIFO order.
