Synchronous re-ordering operations corrupt composite assets and collections

Log in on two machines or two browser as two different users (Regular Members)- User1 and User2.

As User1- Create a collection and then add three assets in order (Asset1, Asset2 and Asset3)

Now as User2- find that collection and edit it (While User1 still has the collection open in the CB). User2 removes Asset2 from the collection.

After User2 removes Asset2, User1 (Without re-loading, so they still see all three assets in the collection), moves Asset1 to the top of the collection using move.

The composite asset it now messed-up. There are a few issues related to this:

Problem #1- The element ordering is now incorrect, It has two asset #3 (In position 0 and 4),
Problem #2 - (And more important in a way) the history is not correct. The compost asset history stopped at V1.4 when it should be 1.8 (See example)
Problem #3- When moving an asset to the top, it should not go above a CBOE if that is on the top. Need to consider CBOE position when moving (Above or below)

Here is an example:

http://next.dev.curriki.org/xwiki/bin/view/Coll_Flerp/Synchronousresorttest

Consider the History which does not show the creation of the sub assets (AS it should), the removal of Asset2 or the moving of Asset3:
http://next.dev.curriki.org/xwiki/bin/view/Coll_Flerp/Synchronousresorttest?viewer=history

Compare to this collection which was made the same way, but without the re-ordering and removal of an asset:
http://next.dev.curriki.org/xwiki/bin/view/Coll_Flerp/CollectionHistoryTest1

Also click on one of the asset#3's and notice the TOC

This is one of an entire class of issues that can also be triggered by one person adding from the main site at the same time as another is editing the same collection in the CB. Any time two people are changing the order of a collection at the same time, these issues can happen. In all cases when a save is to occur that would change the asset order or count of assets in a composite asset, the system should update and adjust (refresh) before committing the change. If the update indicates an impossible condition (Like moving a resource that is no longer in a collection), then an appropriate message should occur. A related condition is when a user edits a resource in the context of a collection in the CB at the same time another user remove that asset from the collection- The save should occur, but after the CB refreshed and the user informed that the resource has been removed and to reviewer the collection or add it back in.

We need a simple and generalized approach to handling all issues of this class.