Lambda the Ultimate

You could easily express this in Scala using path dependent typing, but you'll have to nest style handle in document:

class Document {
  class StyleHandle {...}
  def NewStyleHandle(style : Style) : StyleHandle;
  def AddContent(content :Text, styling : Style Handle);
}

Class nesting in Scala is much more powerful than Java since the object type prefix is used rather than the class type prefix; e.g.,

val a = new Document();
val b = new Document();
a.AddContent(c, b.NewStyleHandle(s));

will be rejected by the compiler since a and b aren't the same objects.

More generally, I've been working with "slot" based type systems where you can express object graph type relationships. See my Maze of Twisty Classes paper if you are interested in learning more. The idea is to allow us to express arbitrary type constraints within the object graph, not just ones based on one dimensional nesting.

I'd really be interested to hear about other related work that anyone knows about.

Not sure if I understand your problem correctly, but in C# with anonymous types, a possible lightweight discipline pattern I'd suggest to handle this would be something like:

Document a = ...; // in scope, as a local, or param, or field/prop
                  // along with Text c, and Style s

var rendering = new {

  Document = a

};

rendering.Document.AddContent(c, rendering.Document.NewStyleHandle(s));

(where 'rendering' is the anonymously typed guy enforcing the correct scoped document instance)

... Maybe (?)

Just a conventional pattern. Pretty unambitious anyway, but quite simple.

EDIT
1. again, nothing thrilling really, just a pattern applicable in C# 3+ or other language with a similar notion of 'anonymous' types (anonymous to the programmer, though not to the compiler in C#'s case which does craft a class type behind the scene)

2. in the pros, besides simplicity: this notion of anonymous types a la C# makes those 'rendering.Document', etc, auto crafted properties not only statically typed but also read only, with reason; thus, no risk to have some LOC (before the AddContent call site) mischievously reassigning the document instance of concern at hands in that 'rendering.[something]' reference path, behind your back

3. in the cons: for simplicity, I assumed AddContent and NewStyleHandle are part of the Document type spec; but if those are in fact held elsewhere, this pattern will require an additional effort/LOC overhead via, e.g., extension methods in scope over 'this Document...' (another C# 3+ specific)

The second best thing is to rule out errors with a type system. The best thing is to make errors impossible to express in the first place. Perhaps there is another way to refactor your API? For example instead of making a new style handle by passing in a document, and then attach that style handle to the same document, you could have a GetStyleHandle on a document and remove NewStyleHandle. That way it's impossible to create a style handle that gets attached to the wrong document.

If you really do want to do this with types, existential types may help. They allow you to ensure that values passed back into a module are the same as you got out of the module.

The signature would become like this:

function NewStyleHandle(doc : Document[T], style : Style) : StyleHandle[T]
function AddContent(doc : Document[T], content : Text, styling : StyleHandle[T]) : Void

Now you can only pass a combination of Document[T] and StyleHandle[T] to AddContent where the T's match up, and the only way to get a StyleHandle[T] is from a Document[T]. NewDocument would have the type Void -> exists T. Document[T].