Revisions in several cultures

A node starts with one version. EnableRevisions, or its first CreateRevision, turns it into revisions: versions with an id, a RevisionType, a culture and values of their own.

db.EnableRevisions(id, out var english);                       // the current version, published
db.ChangeRevisionCulture(id, english, "en-US");                // ...becomes the English one
db.CreateRevision(id, english, RevisionType.Published, out var norwegian, "nb-NO");
db.CreateRevision(id, norwegian, RevisionType.Preliminary, out var draft);   // a Norwegian draft

// Publish the draft: archive the published Norwegian version in the same transaction
db.Execute(db.CreateTransaction()
    .ChangeRevisionType(id, norwegian, RevisionType.Archived)
    .ChangeRevisionType(id, draft, RevisionType.Published));

When you write:

Values are never copied between revisions. Publishing the nb-NO version leaves en-US as it is. A write in a context that selects a revision changes that revision only.
A culture has at most one published revision. To publish another, archive the current one in the same transaction, as above.
A node's versions are all neutral or all in cultures. A neutral node given a version in a culture moves all its versions into that culture. So if it has a published version, a new published one in that culture is refused: make a draft and publish it over that one.
ChangeCulture(id, code) moves the whole node to a culture, or to none with "". It is refused while the node is published in two cultures. Insert(node, cultureCode) inserts in a culture.
A culture in use cannot be deleted.

When you read:

A reader gets published revisions only: its culture's, or with CultureFallbacks a neutral version or another culture's, in the order the cultures were created. A node with nothing to read is left out of queries and is not found by id.
With Unpublished(), the culture's own revision comes first whatever its type, so an editor finds a node that has only a draft.
QueryContext.SelectedRevisions picks one revision per node, by node id and RevisionKey. Look the key up with db.Datastore.GetRevisions(id): it changes with the revision's type, unlike its RevisionId. A selected revision is read whatever its type and dates, in queries and relation ends too, which is how you preview a draft. Access and culture rules still apply.

What the indexes hold:

Published values only, so a Where, a sort or a search never sees a draft's values, even a selected one.
One version per node: the one a reader with no culture gets. Mark a property CultureSensitive (a datamodel override) to give it an index per culture as well, so queries in a culture see that culture's values. The store setting CultureSensitiveTextIndex does the same for search.