This is fixed in the -05 version. The only significant point is about the
details of Query message encapsulation. 5.3.2 explains the general principles,
and 5.3.2.2 gives the details for the path-coupled message routing method.

I would propose to close this issue by saying 'yes'.

In detail: 

*) para 1 is background, and is either obsoleted by the proposed solutions to
Issues 2 and 30 or already implicit in the rest of the document.

*) the rest of the issue is about source address selection for implicitly
addressed messages. The discussion to date suggests that there is no answer to
this question which is 'correct' for all circumstances, and both options may be
reasonable.

Issue 30 resolution text states that the encapsulation is not semantically
significant for the signalling, so the choice of which to use can be left up to
the message sender. Flags in the common header will indicate which was done. The
specification will indicate that a local policy can be used to decide which
approach to use per message transmission (including changing the policy on
retransmissions of the same message where this is done inside GIMPS). Using both
in parallel should not be allowed.

The discussion in Section 4 essentially assumes that
datagram mode messages are UDP encapsulated.  This leaves
open the question of whether other encapsulations are
possible, and exactly how these messages should be
addressed. As well as UDP/IP (and raw IP as discussed and
temporarily ruled out in Section 9.2), DCCP/IP and UDP/IPsec
could also be considered as 'datagram' encapsulations. 
However, they still require explicit addressing between
GIMPS peer nodes and some per-peer state to be set up and
maintained.  Therefore, it seems more appropriate to
consider these encapsulation options as possible messaging
association types, for use where there is a need for
congestion control or security protection but without
reliability.  This would leave UDP/IP as the single
encapsulation allowed for all datagram mode messages.

Addressing for upstream datagram mode messages is simple:
the IP source address is the signaling source address, and
the IP destination address is the signaling destination
address (compare Figure 1).  For downstream datagram mode
messages, the IP destination address will be the flow
destination address, but the IP source address could be
either of the flow source address or signaling source
address.  Some of the relative merits of these options are
as follows:

a) Using the flow source address makes it more likely that
the message will be correctly routed through any
intermediate NSIS-unaware region which is doing load sharing
or policy routing on the {source, destination} address pair.
 If the signaling source address is used, the message will
be intercepted at some node closer to the flow destination,
but it may not be the same as the next node for the data
flow packets.

b) Conversely, using the signaling source address means that
ICMP error messages (specifically, unreachable port or
address) will be correctly delivered to the message
originator, rather than being sent back to the flow source.
 Without seeing these messages, it is very difficult for the
querying node to recognise that it is the last NSIS node on
the path.  In addition, using the signaling source address
may make it possible to exchange messages through GIMPS
unaware NATs (although it isn't clear how useful the
resulting messages will be, see Section 6.3).

It is not clear which of these situations it is more
important to handle correctly and hence which source
addressing option to use. (RSVP uses the flow source
address, although this is primarily for multicast routing
reasons.) A conservative approach would be to allow both,
possibly even in parallel (although this might open up the
protocol to amplification attacks).