Differentiating between deletes and updates while processing user library changes

In the V1 APIs dropbox files didn't have an id field, we had to rely on the path as the unique identifier for a file.

So, when processing changes to a user's dropbox library such as a file rename or a move we get two metadata delta entries - one for the delete and the second with the updated path for the move or the rename.

With the V2 APIs introducing the concept of an "id", I was hoping this would make the process of tracking changes easier, but so far it looks like it is no different from the V1 way of processing changes.

We still get two entries back for the update when we call the list_folder/continue with the cursor. The first entry has the ".tag" : "deleted" with the old path and the second entry has the ".tag" : "file" with the metadata of the same file with the update path (id remains the same).

The issue here is there is no way to differentiate between an update and a delete just by looking at the list_folder/continue response.  

Here is a github gist of an example response where a file name has been updated https://gist.github.com/anonymous/e9c3fcae037b2bd68b74

It would make things easier if we do not get a "deleted" entry for updates and only get it for actual deletes.

Another option that might make things easier is - for deletes if the ".tag" : "deleted" entry had the "id" in addition to the path we can at least make the distinction between deletes and updates. In other words, the "deleted" entry for updates will only have the path, while the "deleted" entry for actual deletes will have both the path and the "id". This option is a hack, but it could make life easier for people trying to differentiate between deletes and updates.