What is the time resolution of Cosmos DB Change Feed?

It is my understanding (e.g. from here) that the Cosmos DB Change Feed is not guaranteed to trigger an event for each update. For example, when two updates to the same document occur almost simultaneously it can happen that the Change Feed Processor (e.g. an Azure Function listening to the Change Feed) is triggered only once, namely for the later of the two updates. First of all, is my understanding correct? If yes:

1. What is, from your experience, a typical minimal time interval for updates such that a change event is triggered for each event individually? (Not an exact value, but just the order of magnitude would already be helpful.)
2. Is there an SLA for this time interval?

Change feed is polling based rather than event based though so depends how often you poll for changes with the incremental model.

The processor just keeps track of the highest LSN it has read per partition and requests the next batch of changes from that bookmark point onwards (in LSN order).

Every time a document is updated its associated LSN is increased so, in order for a specific version to be returned in the change feed, the change feed processor would need to request a batch containing that LSN before the document is updated.

For Azure functions you can reduce feedPollDelay to make it less likely that you will miss changes

(Optional) The time (in milliseconds) for the delay between polling a partition for new changes on the feed, after all current changes are drained. Default is 5,000 milliseconds, or 5 seconds.

If your changes are very close together you will likely still miss them though. There is a "full fidlelity change feed" option coming at some point that will return all changes but I'm not sure how to get onto the preview or when it will be GA and integrated with Azure functions.