(1) You can in some configurations. If you use qemu there's a block-device driver in qemu and another on the GlusterFS back end (as of 3.4), which both allow snapshots via methods external to us. I meant what I said about it being a hard problem. We're determined to deliver a
general snapshot function. That's much harder than delivering snapshots that rely on an uncommon and/or unstable base technology, so it's taking a while.
(2) Yes, if you want to survive N concurrent failures you need N+1 mount servers, and currently released code only supports N=1. However, http://review.gluster.org/#/c/5400/ has already been merged and will be available in the next release.
(3) IMO you should also have mentioned that the problem only manifests in a specific deprecated use of the CLI (from machines other than the servers). Nonetheless, this is a known deficiency which I've been personally pushing to fix.
(5) The current state includes many of these "cool features" (thanks!) without need for any specific OpenStack integration. That's kind of the point. Unlike some, we don't need to re-implement features for every access method or use case. 90% of that functionality would be available e.g. to CloudStack or OpenNebula today. IMO making a big deal of snapshots as a differentiator in one direction without mentioning myriad differentiators in the other doesn't leave people with the information they need to make progress toward their own decisions.