Impossible to mix as in impossible to wait on mixed inproc/server objects, and we have to fallback to wineserver if any inproc sync of the objects waited on is unimplemented,
Or impossible in every use case, and every object type has to be implemented before any of this can work?
The latter. The state is not kept in sync, and fundamentally cannot be, and because waits are vectored this cascades. Believe me, I tried, if there was a way to pull it off we wouldn't need the kernel support in the first place, because we could just do in-process waits using futex or something, until we ran into a handle that had been shared cross-process.
If this is the latter, what happens if any new object type needs to be added in the future? Does it block any server-side implementation until there is support for it in the kernel?
All objects other than the "big three" of semaphore/event/mutex can be implemented on top of an event. In all cases this is a manual-reset event except for auto-reset timers. The server manages setting and resetting that event.
*If* there were another object introduced with complicated "consuming" semantics (i.e. wait affects state) that couldn't be emulated on top of another object, then yes, ntsync would be broken until we add kernel support for it. I wouldn't say it blocks server-side implementation, since it would end up being a matter of "disable ntsync or have a potentially broken setup", but server-side sync would still work.