Technically speaking, it appears they might be longer, in the future:
Unique version IDs are randomly generated, Unicode, UTF-8 encoded, URL-ready, opaque strings that are at most 1024 bytes long
http://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html
However, there doesn't seem to be an explicit statement as to the scope of these identifiers.
The bucket versioning documentation (now) includes this statement:
When you enable versioning for a bucket, all objects added to it will have a unique version ID.
Assuming this is correct as written, the version ID is scoped to the bucket... but I am still skeptical. S3 sometimes performs index partition splits on buckets for performance reasons, and unique version ID maintenance across partitions seems somewhat unlikely. It really depends on what the information in a version ID actually means, if it means anything at all. It's opaque, so for all we know, it could be random.
In the strictest sense from an application's perspective, they are only unique to the individual object, because if objects are created in an unversioned bucket, and versioning is later enabled on the bucket, every object that existed when versioning was enabled has the same version id, which is the literal string null
when you are interacting with the REST API.
In any event, though, a version ID isn't meaningful in the absence of the acconpanying key, because you can't fetch an object by version id alone -- only by key + version id.
Taken together, the appropriate course of action would seem to be to work with the assumption that version ids are scoped to, and only meaningful at, the object key level.