According to the research I\'ve done (see for example this gae issue and this stack overflow question), it is not possible to share one datastore across two applications, an
The code which interacts with persistence layer and datastore should be same across all versions is biggest thing you should take care of (Assuming they are doing operation on same set of entities). Since datastore is entity based, and it's upto your application to manage entities, so it's very easy to have a different persistence code and create anamolies in DB. UI and business logic layer should be fine as such.
Using multiple versions for this is a fine way to do this, and there is no problem with the terms of service -- however you may not be able to provide round-the-clock service for multiple apps using only the free quota.
Do note that this means that you have to be extra careful about using the correct version when updating an app, and you can't easily use versions for other purposes simultaneously, since the version is now part of the URL that users use to access an app.
Also, admin console permissions cannot be differentiated between different versions.
Finally, there may be some scheduler features (maybe instance control?) that only apply to the default version; I'm not the right person to answer that.
One reason for not doing it would be that every deployment will come with a temporary outage - between when the instances running the old code are being shut down and instances running the new code are started. Gradual/graceful traffic switchover is not possible (it requires different versions).
Occasionally these outages can be extended, requiring human intervention for recovery, see Continuous integration/deployment/delivery on Google App Engine, too risky?.
Another reason would be trouble mapping such version-based "apps" to custom domains, see How to use custom domain name in google app engine with different versions?
FWIW, these days a much better way to achieve the same result is using different services/modules for such "apps", see Service isolation.