The main issue, in my mind, is that you have several examples which will never be handled by a generic client without some hand programming.
Any complexType which adds attributes is going to require hand coding. There is simply no generic interpretation of how to handle values that are in both attributes and as element content.
I wouldn't sign the above statement. While it is common sense that xml/xml-s idiosyncrasies are critical when using xml as representation/ streaming format, it is a question of design whether to you want developers of your framework to express these more or less subtle differences when creating their mappings.
The attribute vs. element issue is one of the most trivial cases IF considered isolated from other xml/xml-s idiosynchrasies. It gets more complex once you consider the nillability constraint, just to name a prominent one. The approach taken by most frameworks (Axis, .NET, ...) is to generate per-type marshallers (note that "type" refers to "class type" with classes being representations of element types) from xml-s descriptions embedded in wsdls. They, then, take care of streaming ("serialising") certain members of an object into element attributes. It's a rather declarative approach.
In the end, it boilds down to the question for which overall purpose you want to conceptualise and devise your framework, which "remoting" lifecycles you want to support!
In conventional (OO)-RPC middleware, you deal with rather atomic, operation-level interactions (of objects) which may allow a design that simply rejects element attributes as representation flavour. This is fully valid and acceptable! In this life-cycle, developer devise procedures or objects first, representations come second. Once you enter other scenarios, where "document/ content models" are devised first, and language representations (procs or objects) are secondary, you end up with the need to support more of the xml/xml-s idionsynchrasies. This key distinction is also prominently mentioned at the beginning of the article posted above with the authors referring to schema-first vs. object-first approaches.