If I say "students can be registered for courses in the school" then you might think the OO model should be

    school.register(student, course)

which does actually seem reasonable to me. Here the school object would basically be the system's logic as a whole, and both the course and the student could just be IDs.

I really think single dispatch OO is a huge distraction and I haven't seen any strong arguments for its use as a general paradigm.

Nothing about DDD says you can't use multi-dispatch. If this how you think about the problem. Then this is your solution if your language is capable of expressing it.

Yeah, I'm quite a big fan of Eric Evans and DDD. Especially the more high level parts about ubiquitous language, bounded contexts, anti-corruption layers, and many of the other patterns. Yet I think that the focus on single-dispatch OO kind of dates the book and makes it less general and beautiful, much like how the GoF's "Design Patterns" book is more banal than Christopher Alexander's work on pattern languages because of the overemphasis on specific implementations of single dispatch OO patterns (the notorious visitor pattern, for example).

If the pairings of courses and students are registered in the school object, then that's basically OO implementation of a many to many relationship of students and courses.

That's why I like Django. You just tell it that you want a many-to-many between students and courses and it does they for you, symmetrically, without forcing you to introduce a class such as "school".

Bi-directional models come with their own problems.

That's wishful thinking.

All your trying to do is match their language, so its easier to develop against a description of a use case. Technically either way allows you do what you want to do.