As this thread seems to be the only thread around, coping with this issue in a serious and advanced manner, and without being choked by contributors not getting the thread's matter, I'd like to point out some further hints regarding this–IMHO very serious–flaw of Matlab.
First, except for the initializing method, one does not necessarily have to write the proxy method WrapperClass/<action> in order to invoke the <action>_mex functions: only declare the <action> method in the class definition and place the mex files in the @WrapperClass directory immediately... you have to implement mexFunction() anyhow, which is another proxy function already and which can take over the part of fetching the C++ object pointer from the Matlab object with mxGetProperty(). I admit, this concerns exclusively code aesthetics but it might slightly improve code maintainability and oversight.
Second, I just started to follow another route for tackling this problem: Java-Interfaces of native objects, which allow you to wrap C++ classes with Java-Interfaces. Latter can instantly be instantiated in Matlab. Unfortunately I haven't had the time to check how transparent type interoperability between both environment-transitions can be realized. Has anybody had some experiences with this approach so far?
Perhaps somewhat off-topic, but still related to the context of my first point, I'd like to ask if anybody has figured out what exactly happens to Matlab objects derived from handle-class when they are being passed to mex-functions? I mean, value-classes get deep-copied at environment-transitions, just as at conventional function-/method-transitions, but what happens exactly to handle-objects, do one has to deep-duplicate it on mex-level to return object changes and then deep-copy back the fields and properties of the duplicate to the original object to preserve behaviour of handle-objects?
Thanks for your points of views, ideas and thoughts.