There was a discussion between Trond, Dustin and I on this earlier today. The discussion wasn't conclusive, but addressing this issue pretty much comes down to two options:
1) Find a bit somewhere (tap flags?) to indicate whether or not item flags are in the correct order. This would allow us to, in a future release, turn on this bit and correct flag ordering when all nodes of the cluster are known to handle it. It would also allow us to immediately workaround in the issue in any TAP clients by reordering now (on the assumption that it's wrong, since we support only one architecture at the moment), and not reordering if the bit indicates the response is now correct.
2) Document that item flags in TAP will be sent in the wrong order from certain architectures and that clients should reorder.
Option number two isn't so nice in that it complicates ever-so-slightly client implementation, but more importantly makes it impossible to do TAP between different architectures whether server to client or between servers.
Trond also mentioned that fixing it isn't exactly easy, as it's memcached that converts and it's not possible to know what to change at that level. The fix there would be to ntohl() that part before returning it to memcached, but then it'll be converted again. This makes bytes correct, but would be a bit confusing in the code and not exactly the best way to handle them.
If possible, I'd like to get a good answer on this as there are updates needed very, very soon on the Java client to work with this. The requirement is that what we ship work with 1.8.0, so I know I'll need to reorder in the client for now, but would like to put it together in light of whatever long term approach we decide upon.
See also http://review.couchbase.org/13510
which has a change for the Java client to do the mentioned reordering and further discussion.