XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

There's been some recent discussion in the webkit-dev mailing list about the
efficiency of implementation of the "responseArrayBuffer" attribute.  People
are concerned that it would require keeping two copies of the data around
(raw bytes, and unicode text version) since it's unknown up-front whether
"responseText", or "responseArrayBuffer" will be accessed.  I have a few
possible solutions to this problem:

1.  Defer decoding the text, and instead buffer the raw data as it comes in.
 If there's any access to responseText (or responseXML), then the buffered
data can be decoded into text at that time, and the buffered raw data
discarded.  If that case happens, then from that point on no raw data
buffering would happen and the text would be accumulated as it is right now.
 Otherwise, if responseText is never accessed then the raw data continues to
buffer until it's completely loaded.  Then an access to responseArrayBuffer
can easily convert the raw bytes to an ArrayBuffer.

The idea is that once responseText or responseXML is accessed, then it would
no longer be possible to access responseArrayBuffer (an exception would be
thrown).
Conversely, once responseArrayBuffer is accessed, then it would no longer be
possible to use responseText or responseXML (an exception would be thrown).
This approach does seem a little strange because of the mutually exclusive
nature of the access.  However, it seems that it would be hard to come up
for a reasonable use case where both the raw bytes *and* the text would be
needed for the same XHR.

2. Darin Fisher has suggested this approach: Add an "asArrayBuffer"
attribute (similar to "asBlob") which *must* be set before sending the
request if there will be a subsequent access of the "responseArrayBuffer"
attribute.

3. Get rid of the "asBlob" attribute and add a new "responseType" attribute
which could be:
"Text"   <--- this is the default
"XML"
"Bytes"
... other types yet to be defined

Approach (2) can lead to illegal combinations (both asBlob and asArrayBuffer
set to true), but approach (3) is not as discoverable at runtime as (2),
because (2) allows for the simple existence check of either attribute
"asBlob" or "asArrayBuffer".

I can accept any of the proposed solutions and would like to hear what
others think about these or other approaches.

Chris