Updated 3D model with some new design ideas:

• Lengthened the mouthpiece box from 48mm to 80mm to allow more space for the mouthpiece to provide very complete set of capabilities as the processor for an entire instrument.  For example there's more room for a display, an IMU, a reasonable sized LiPO battery and maybe wireless, although only a display connection point will be on the next version of the PCB.  I kind of liked the look of the shorter mouthpiece better but as this image shows, the longer mouthpiece should be okay too.  At 80mm (just over 3 inches) even the longer design is not much longer than a sax mouthpiece.  
• Edit: I think at 80mm the mouthpiece just looks too long!  For the final version I may use a chop saw to shorten the 80mm standard Hammond tube by about 15mm.  However the latest PCBs I ordered are based on an 80mm tube.  I have an idea for a way to allow the same main PCB length to be used in tube lengths of the user's choice, although always the same width.

• Added a new sensing system that I think will be capable of measuring downward force on the top of the mouthpiece.  This image shows a reflective photosensor with a  "blade" 2mm above it.  The blade (just below the screw) should move over a range of about 1mm back and forth across the sensor in response to downward force on the mouthpiece.  This should strongly vary the amount of light reflected which should be easily measurable by an ADC.

  The following images show how a plastic "spring action" is proposed to be fabricated into the back bezel.  The attachment point for the back bent-wire bracket is separated by a slot from the main bezel on all sides but the top creating a "flap", and clearance is provided so the mouthpiece is free to pivot slightly with respect to the support arms.  I think that assuming the support wire is held reasonably firmly the flap should flex slightly causing the blade to move across the sensor.  The back bezel will be 3D printed so it should be easy to adjust the stiffness of the flap and blade position to optimize the responsiveness of the sensor.  If it works this could provide a very nice, sensitive and easy to learn controller usable almost entirely independently from the lip and oral cavity sensors.  I'll find out when I build the next prototype.

• Added a connector (light orange below) that should allow the entire unit containing the mouthpiece sensors to be unplugged from the mouthpiece PCB.  If this works it should make assembly and testing easier. 

• Also changed to the NXP MPX2300 pressure sensor.  (Visible in the above image). The Honeywell ABP Series in the previous design proved to be difficult to get with the exact specifications I needed.  I've used the MPX2300 in two previous designs and it's very nice, but its port is surprisingly difficult to connect to.  However it's medical grade and inexpensive, even adding in the cost of the required instrumentation amplifier.  It also can be set up as differential which means it will be possible to sense both blowing out and sucking in.  For some applications sucking in can offer a unique alternative channel of control.  For example play a different sound, step to a different patch, or whatever you choose to enable in the software.  Note that the widely used NXP MPXV7002 pressure sensors are too big to fit in the Hammond extrusion box I like for the mouthpiece.

Updated the PCB design to accommodate the new ideas.  Also added jumpers to allow the Grove connector to be used for either I2C or serial.  I suspect that serial connection to finger units may be easier to develop and more reliable than I2C.  This would require that a finger unit have it's own Teensy processor to adapt the serial protocol to various sensors but it should be easy to design a finger unit board with a Teensy, serial connection to the mouthpiece plus I2C or other ports for a variety of sensors.  The plan would be to develop a human readable ASCII serial command language to allow mouthpieces to interact with finger units and for data transfer.  There would be the overhead of converting data to ASCII but the Teensy 3.2 should be powerful enough to handle it.  Flow control would be an issue but I think a high enough data rate could be maintained without the need for flow control.  A mouthpiece with a serial interface might also allow it to communicate with a host computer over an FTDI dongle, which would be nice for debugging and might be a nice way to bypass midi to give packages like Max/MSP access to the raw data.  Here are some images of the PCB I just ordered:

The PCBs should get here next week.  I'll report back on the results when I build and test the new version.