I've had that issue since joining the site. I'm curious if it's just a little thing that is not important or if there is a solution. While it does not impede my enjoyment of Elliquiy, I'm curious what causes it?
Caching is a mechanism by which data gets stored in some intermediate form for faster access.
The value itself is denormalized - rather than calculate it each time (which would be expensive) it just gets stored as an integer that gets incremented when you get messages and decremented when you read them - it rarely gets out of synch, but in theory is possible for it to do so. I have to fix these instances manually.
This value then gets cached to the server's RAM as raw data (along with everything else, at least for a few more months until our database outgrows its ram allocation again). Queries which read said data get placed in the query cache. These are both well-tested caches, and though the latter has a number of issues, it won't return invalid results.
From there it gets handled by the software - SMF uses php's APC cache, as well as its own on-disk cache. Caching was unfortunately added as an afterthought to SMF 2.0 rather than built with such in mind, as [Unknown] himself admitted. It's functional and works, obviously, but some people experience delayed data because it doesn't always properly invalidate the cache on an update.
The database and caching handler was one of the first things I completed properly for the new CMS. As such it's much more robust there.
I've started having it since moving over to the https: protocol. I don't know if it's coincidence or not, but if I hit 'cancel' the second time that the 'Do you want to open the message in a new tab' box appears on my screen (after I know that I've read the message(s),) it seems to stop the popup until there's a genuine new message.
This should resolve itself once https gets forced.