Tecnicamente falando, parece que eles podem ser mais longos no futuro:
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
No entanto, parece não haver uma declaração explícita quanto ao escopo desses identificadores.
A documentação de versão do bucket (agora) inclui esta declaração:
When you enable versioning for a bucket, all objects added to it will have a unique version ID.
Supondo que isso esteja correto como está escrito, o ID da versão é definido para o intervalo ... mas ainda sou cético. Às vezes, o S3 executa divisões de partição de índice em intervalos por motivos de desempenho, e a manutenção exclusiva de ID de versão entre partições parece pouco provável. Isso realmente depende do que a informação em um ID de versão realmente significa, se é que significa alguma coisa. É opaco, então, pelo que sabemos, pode ser aleatório.
No sentido mais restrito do ponto de vista de um aplicativo, eles são exclusivos do objeto individual, porque se os objetos forem criados em um bloco semversão e o controle de versão for ativado posteriormente no bloco, todos os objetos existentes quando o controle de versão tiver sido ativado mesmo id de versão, que é a string literal null quando você está interagindo com a API REST.
Em qualquer caso, no entanto, um ID de versão não é significativo na ausência da chave de associação, porque você não pode buscar um objeto somente pelo ID de versão - somente por chave + ID de versão.
Em conjunto, o curso de ação apropriado parece ser trabalhar com a suposição de que os IDs de versão têm escopo e são significativos apenas para o nível de chave do objeto.