ok, power on issue - interesting findings 
tl;dr; I think its a corrupt midi stream.
when using a direct DIN connection.
above tests:
is DIN and USB disabled on Osmose?
Yes/No
DIN is not working, even when used from above hardware device.
USB however is working still.
so its just disabling the DIN.
this one was interesting…
so I tried all combinations going via the mioXM.
ET (usb) → mioXM → Osmose (usb)
ET (din) → mioXM → Osmose (usb)
ET (usb) → mioXM → Osmose (din)
all worked…
of course, I then noticed that Ive got sysex filtering turned on in the mioXM - doh.
so I turned off sysex filtering, so nothing is being filtered
and… drum roll…
again tried…
ET (din) → mioXM → Osmose (din)
it still worked !
SO where are we , well, essentially the mioXM is just doing a pass thru on DIN now.
and it works fine, whereas a direct connection does not.
I have had similar experience before where the mioXM fixes things… even when acting as a pass-thru.
I believe the reason is, the mioXM is a ‘soft thru’ , it is interpreting every midi message and then re-broadcasting it. (it has to , as it can filter, go to multiple targets etc)
Ive noticed, before the stream is NOT identical to the stream out… ( * ) and this cleaned up stream seems to be more compatible, which could be the reason.
the other reason, is perhaps, the mioXM is a bit better at things like flow control… perhaps the ET is overflowing the input midi buffer on the Osmose, but the mioXM prevents this.
obviously it provides a solution for me (go via mio xm !), but it makes it difficult for me to track down the exact issue… and to know if its an ET/Osmose/Haken Engine issue.
ok, now to reassemble my setup… put cables back where they should go!
testing is such a mess!
( * ) there is a notion of ‘running’ (?) messages in midi, which allows you to reduce the amount of data transmitted in the case to sending the same CC consecutively … it was used extensive for midi din, with its limited bandwidth, but does not buy you anything over USB (USB MIDI uses fixed 4 byte packets)
what Ive noticed in the past is the mioXM will convert these running message into ‘standard’ 2 byte packets… this can help with some devices that don’t support this running message.
so it could be this the source of the issue during startup.