Indeed. 
1. From practical standpoint, the range varies the response.
for e.g. initial request might have asked for bytes 0-99, and got back etag=1234. Second request was for bytes 100-199, even if the etag match, the client never got back bytes 100-199.
So why return etag on partial responses to begin with?
If the client would issue a PUT request with the range, and If-Match header, then the etag would act as the MVCC differentiator.
2. From spec standpoint this is how I understand the RFC (2616 14.35.2), specifically:

        The presence of a Range header in a conditional GET (a request
        using one or both of If-Modified-Since and If-None-Match, or
        one or both of If-Unmodified-Since and If-Match) modifies what
        is returned if the GET is otherwise successful and the
        condition is true. It does not affect the 304 (Not Modified)
        response returned if the conditional is false.

The condition is true in the GET with If-None-Match case (thus "ignoring" the header) and is false in the PUT with If-Match case (in which I believe we don't even support Range header anyway)