That seems sensible. I'm glad you are questioning this at the very beginning.
JS conflict resolution in my eyes makes sense if we build some kind of ORM or three-way binding solution (we'd obviously create just client-model-to-server-model binding part, the rest is up to the MVC framework).
I also believe that Conflict Resolution API shouldn't be much different from our Realtime sync from the API standpoint,
the real difference is that Conflict Resolution can easily intergrate with existing concepts and backends because of its RESTful nature,
while Realtime sync requires special backend handling (aka sync-server):
Sync.save(objectInstance);
Additionally, Conflict Resolution has points on the roadmap that goes far behind regular framework principles: Partial Updates, Batch Updates, Server Notifications...
As discussed on F2F, we should though always think about how this integrates into wider picture (existing frameworks).
For this moment, we could start just with examples, they could also demonstrate us what deficiencies existing solutions have.
And if nothing, the only deliverable for conflict resolution at the end maybe a cookbook, a doc/guide and maybe some contributions to upstream :-)