The intended design for change notifications is that other than inside a write transaction, it should be impossible to ever read a new value from an object without first receiving a change notification related to that new value. This is very important for things like UITableView which have their own internal tracking of the row count - if the results of a query changes without a notification being sent first, UITableView may request a row index which is now out of bounds.

Currently when a write is performed on the same thread as notifications are registered on, the write is applied to the read state immediately, and then notifications are asynchronously sent later. This leaves a window where the new state can be read before the notification is sent. With UITableView this happens to work out fine most of the time, but if two writes are performed in a row, the refresh triggered by the first write often happens before the notifications for the second write are sent.

Performing writes on a background thread avoids this, but is sometimes difficult to do.

There's two potential solutions I can think of:

1. Synchronously send notifications immediately after committing a write transaction. This is the easiest to understand thing and would eliminate some existing user confusion. Unfortunately, it means doing a large amount of blocking work on the UI thread, which can often take longer than the write itself.
2. Don't advance the read transaction version when committing a write. We could commit the write transaction but roll back the Transaction to the initial read version, resulting in the writes not being visible until the next refresh happened. This would make on-thread writes behave almost exactly like off-thread writes, which is a nice bit of consistency. It's probably also extremely surprising and confusing to the overwhelming majority of users. KVO would need to send rollback notifications.
3. Expose an API to give the user the option to do either of the above.

These are both easy to implement but seem bad. Hopefully a better solution is possible.