It seems to me that you're confusing cloud block storage solutions like Rackspace's Cloud Block Storage or Amazon Elastic Block Store with the management of actual network storage hardware. When you launch a cloud server, you don't get anything like a public iSCSI endpoint to attach your own storage to; since iSCSI is cleartext that would be a giant security hole.
Instead, cloud providers offer block storage as a layer of abstraction over network (or local) storage solutions within the datacenter your server is actually located within. You can think of block storage like a virtual USB key - you can plug a volume in to a server, mount it like any other drive, read and write files on it, then detach it and re-attach it to another - and ideally you don't have to worry about the mechanism that's physically used to accomplish this (as long as your performance is satisfactory, of course).
Points A, B and C under "file storage" really sound to me like they're describing object storage, like Cloud Files or S3, instead. You generally don't mount these directly like a drive (although it is technically possible), and instead use them through a REST API of some sort. They offer the potential of much greater storage capacity than you'd get on a typical hard drive, with the costs of being eventually consistent and having higher-latency access. On Rackspace, you can also publish them to a content delivery network to do things like host a static website. Useful, but it doesn't sound like what you're looking for.
To answer your specific questions:
Block level storage.
A. Attaching a block storage volume to a server is just like plugging in a USB key or hooking up a physical drive. It exposes raw, uninterpreted device access. So, just like any other drive, you need an OS on a server to format it and do useful work with its data. A volume has no processor, so unless it's attached to a cloud server, it can't do anything useful!
B. When you create a block storage volume at Rackspace, you get to choose whether you want it to be backed by an SSD or a SATA drive, to give you some control over performance tradeoffs: SSDs will be much faster but more expensive. Both are kinds of block storage devices, though.
C. I'm not sure what you mean by "the user side" here. Because of the security concerns I linked before, you can't mount a block storage volume outside of the datacenter it's created in, so you can only attach it to cloud servers within that datacenter. You can't, for example, mount one from your desktop.
D. Snapshots (Block Storage backups) are just byte-for-byte copies of whatever you've put there, so it actually doesn't deal with the filesystem at all.
File level storage.
A. If you are talking about Cloud Files: you don't need specific software because it uses a REST API, so you can use anything that talks HTTP to manipulate it, such as Rackspace's web UI.
B. That's a good question! I have heard other customers request some kind of backup capability, but I don't know where it is on the roadmap. In the meantime, you can use the COPY operation to perform server-side copies of your stored objects and do backups manually that way.
C. Since you generally don't mount Cloud Files containers directly into your filesystem like I said before, you can't use Finder directly to manipulate objects - instead you use the API, an SDK, or the web UI to work with them.