I'm not convinced by the argument of least-surprise. As you said,
there
are explicit commit_unless_managed() calls inside the Django internals
(e.g. inside save() ) - but a Django _user_ (rather than developer)
would
not have read this code before calling save().

So, a Django user who expects Python database adaptors to be
non-autocommit is _already_ being surprised by the fact that save()
behaves as if it is.

By designing default Django behaviour to be "similar to auto-commit",
I think we've already decided that the DB-API default is wrong.

It's now a case of how Django implements the "similar to auto-commit"
behavior most cleanly and efficiently. I think the answer is:
- Get auto-commit connections from Python database adaptors by
  specifically requesting them
- Delete all of the commit_unless_managed() calls
- Change enter_transaction_management() / transaction.managed(True)
  to explicitly issue an SQL BEGIN
- Change leave_transaction_management() / transaction.commit /
  transaction.rollback to explicitly issue SQL COMMIT / ROLLBACK

I suspect that this will significantly simplify the Django codebase
vs.
trying to simulate both auto-commit and transaction behaviors on top
of a transactional connection - it would certainly remove most of the
mechanisms in django/db/transaction.py which track state, dirty, etc.

Cheers,

Richard.