1.
According to the XML Schema for the SOAP 1.1 binding , the soap:binding element's transport attribute is optional with no defaults. The WSDL spec says nothing about the default behaviour if the transport attribute is ommitted. 
In practice, it must be supplied to construct a meaningful binding. In general, because the WSDL spec is somewhat vague in some places about default behaviour where extensibility elements or their attributes are ommitted, it is better practice to be explicit about the binding requirements.  

2.
The WSDL spec shows the soap:fault as having a name attribute but according to the XML Schema for WSDL and the XML Schema for the SOAP 1.1 binding it is the wsdl:binding\wsd:operation\wsdl:fault that must have a name attribute to match up with the corresponding wsdl:portType\wsd:operation\wsdl:fault element's mandatory name attribute. 

If they are both supposed to be there, if a /wsdl:definitions/wsdl:binding/wsdl:operation/wsdl:fault has a name attribute and it has a nested soap:fault with a different name attribute then is it an error or does one take precedence over the other?  

3.
The WSDL spec says in the documentation for the soap:header element that: 

the schema [type] referenced by the [associated message] part MAY include definitions for the soap:actor and soap:mustUnderstand attributes if use="literal", but MUST NOT if use="encoded".

So, for use='encoded', how do we specify a) that a header is mandatory or optional, and b) that a header is intended for a given actor?

4.
From section 3.5 of the WSDL 1.1 spec.

"If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). In the second, the type referenced by the part becomes the schema type of the enclosing element (Body for document style or part accessor element for rpc style)."

So for a document/literal operation the XSD type referenced by the message part becomes the schema type of the SOAP Body element. Does this mean that a document/literal operation can only reference a single message part that uses the 'type' attribute to refer to an XSD type? Can the message only have one such type?

Section 2.3.1 seems to support the latter.

"However, if the message contents are sufficiently complex, then an alternative syntax may be used to specify the composite structure of the message using the type system directly. In this usage, only one part may be specified.  In the following example, the body is either a purchase order, or a set of invoices." 

5.
The WDL spec *says* (section 3.5) that the 'use' attribute is required for the soap:body as does the informal schema fragment in section 3.2. The SOAP binding schema (A 4.2) specifies that it is optional, as does the informal schema fragments in section 3.5.

6.
Regarding the SOAP bindings. If use='encoded' and no encodingStyle attribute is present then (i) is this an error, (ii) do we assume SOAP section 5 or (ii) is no particular encoding assumed (reader must figure it out on the fly)?
 
7.
There is some confusion about where a soap:headerfault pertaining to a particular soap:header has to be encoded - in the 
wsdl:input or the wsdl:output sub-element of the wsdl:binding.

8.
I don't think the array definition shown in example 5 in section 3.1 is not right. Won't it be an array of nothing since the omission of any local element declaration has restricted the wildcard out of existence?