Essentially the way the data caching works is that all data is pulled from the server and stored in the device/browser cache on login (or after cache being wiped, which will trigger re-login too).
After this, any time a user triggers a refresh via 3 dots > refresh (on web) or swiping to refresh (on mobile) the device will push any changes (or new records) made to the server since the last refresh, then query the server for any records that have been updated/created since the user's last refresh and re-pull those records as they now exist on the server.
KIM uses this caching system to allow for offline-first use of the app, where everything remains functional in periods of non-connectivity and changes will eventually be pushed to the server when connectivity is restored and the user refreshes a given page, as will any changes made by other users in that time come back to the user whose device has been offline.
When multiple users modify a record between either user refreshing, cache disparities can arise between the users devices that the server may struggle to process both of before returning the same result to both users, to resolve which the existing cached data must be entirely wiped and re-pulled rather than just the records modified/created since xyz date/time.
Cache issues can also relate to the code running on the site itself, causing differing functionality between two users, as code is regularly evaluated at runtime from the database rather than being active from the moment a user logs in - what sections of the app you're accessing will dictate what code is loaded onto your device's instance of KIM.
After two or more users clear their caches, they should generally be getting the same results as each other, barring any minor time variations between one user fetching the data on their device and another, in which it would be possible for other users to send updates to the server, resulting in a continued cache disparity of however many records were updated in that time.
