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. Just think of a database row: you have one 'array like' list of columns. If you have a complexType with attributes, where do they go (automatically?) Because of this, tWSDL/TWiST store data as element content and don't automatically use attributes for any content. This doesn't mean attributes can't be used (except if you have mixedContent). It also does not mean that tWSDL/TWiST can't store and manipulate XML with attributes, in fact, this is a requirement. An example from
<xsd:element name="Message" type="MessageType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:attribute name="version" type="xsd:string"/>
An example element would be:
So the version attribute cannot be combined with the child elements automatically, but why? First, the attributes and elements are in different namespaces (not xmlns namespaces, but more like how Tcl commands, variables, etc. can have the same name without conflict. Therefore it is possible to have a child element of MessageType named 'version'. (Also on the schema type level, simpleTypes and complexTypes can have the same name without conflict.)
Anyway, although you can't do automatic mapping to an API in this case, the data is still available for hand coding. This is really a minor issue overall. What is more critical to automatic client programming is how reasonable the WSDL description is, and if there are any custom extensions added on to the basic service description. Custom extensions always require developer involvement. Even the meaning of any extension has to be understood by a developer before any code can be written. If the point of a WSDL is to allow for automatic client configuration, then extensions are a great way to remove these benefits. Any SOAP headers fall into the same category, although SOAP headers may be easier to handle.
The TaskManager WSDL imports several tag libraries for special features. This indicates that both the client and server use special programming logic to interact. This is way beyond data handling and representation. In general there is no reason to use special tags unless you don't want generic clients to use the service. All data and types dealing with specialized service configuration could be just as easily delivered via SOAP messages like all other data.
Of course if there is any chaining of operations, this also leads to some need to provide client side programming logic. This is exactly like providing a pageflow on a website. Getting or submitting data via a web service can be the smallest part of the overall client design (this is the typical case).