Set X-Object-Versions header on an object. The header behaves like the X-Object-Manifest header in that it references a container/prefix of other objects in the account. When requested, the "version manifest" will perform a listing based on the value of the x-object-versions header and return the most recent version (the last object when the names are lexigraphically sorted). Likewise a PUT to the version maniest will create a new object name (derived from the x-object-versions header value and the current timestamp) and create a new object.
X-Object-Versions can be added to existing objects. This means that the first version of the object is stored as the data of the version manifest file. We need to take care that we don't lose the timestamp of the first version (since updating the header value could change the timestamp on the first version of the object).
Version listings can be found either by requiring the client to do the listings or by providing a query parameter to return the list of found versions (this would need to support xml and json output, too). A specific version can be fetched with a query parameter to the GET (eg ?version=timestamp).
It should be possible to version manifest files. This can get really tricky (impossible?) if we allow auto-manifest creation by having the first segment of the object in the manifest object. Perhaps a way around this is to simply prevent versioning of manifest files or to prevent versioning of manifest objects if that object is not a zero byte object.