Kind of "auto-resolve mode" and "postponed conflict state"?

When there have conflicting changes been made (say, by users A
and B), the user who is the second one to commit (say, user B)
will have to resolve them. (Since his commit will fail, he will
have to do an update first, the update will note the conflict.)
However, another user might be more versed to resolve the
conflict by hand. Unfortunately, Subversion makes it pretty clear
that user B will have to resolve the conflict.

Mercurial, for instance, allows a "forced push", which means that
the repository grows an additional head. The two heads represent
conflicting changes. *Any* user can then merge the two heads into
one, and this process will later be visible to all others.

This is especially convenient when some users are less
experienced. A less experienced user recognizes a conflict as a
serious error condition ("something's wrong with the SVN!").

I was thinking how to overcome this drawback in Subversion. Am I
correct to presume that anything like "growing additional heads
and merging them into one later" (like offered by Mercurial) is
out of the question due to the way Subversion is organized?

Then, how about a kind of "auto resolve mode". It would mean that
when the update process notices a conflict, it introduces the
usual conflict markers. Then, it automatically marks the conflict
as being resolved (what would otherwise have been done by calling
'svn resolved ...'). Then it commits the files including the
conflict markers. Then another user has a chance to *really*
resolve the conflict. Maybe something like a "soft conflict" or
"postponed conflict" state would be good to allow Subversion to
print a list of all files that still contain conflicts that need
to be resolved by someone. The user resolving the conflict for
good would then remove this "postponed conflict" state manually.

Could something like that be implemented?

Any further suggestions?

Lasse