The point is that if the client has previously fetched and cached a copy of your page (and its headers), and complies with your originally-issued "Expires after one year" declaration, then it will not fetch that page again for one year, and so it won't see your new headers for one year.
Mitigating against this problem is the fact that client caches use a "replace oldest cache entry first" or "replace least-frequently-used cache entry first" policy.
Therefore, it is most likely that the reason you're not seeing complaints is because the old cached pages/headers have already started to fall out of client caches, having been replaced by more-recently-visited pages from other sites and yours.
Whenever you modify server headers, it is a very good idea to check your work with something like the "Live HTTP Headers" add-on for Firefox.
Also, there is almost no advantage whatsoever to declaring expires periods longer than 30 days. You get far more benefit per cache-time-increment with short caching periods than you do for long. That is to say, the benefit of caching for a first hour gives four times the benefit as compared to the incremental benefit of a second hour added to make the total cache time two hours. And the benefit of caching for two hours is much greater per cache-hour than that gained by doubling the caching time again.
To make this clearer, you would see a great benefit in terms of server bandwidth and CPU time saved and page-load time seen by visitors by enabling caching for an hour. You'd gain more, but not as much, by doubling that to two hours. And gain a little bit more by doubling again. But by the time you get to a two-week cache-expiry time, you'll see almost no benefit whatsoever from doubling that again to a month.
The curve of cache-time plotted horizontally versus benefit (reduced bandwidth and CPU time) rises quickly at first, and then levels off. Between the initial "almost vertical" portion of the curve and the final "almost horizontal" portion of the curve is a "knee" where the slope transitions from "mostly vertical" to "mostly horizontal." The location of this knee depends on the nature of your site, and is not predictable without an in-depth statistical analysis of all of the "objects" on your site --pages, images, css files, JavaScript files, etc.-- and how often they are changed and reloaded by visitors. But you can bet that this knee is somewhere between a few minutes and a week -- Anything longer than that is pretty much guaranteed to lie within the "diminishing returns" portion of the curve.
Remember, if the visitor's browser has cached a page, and you have not set the "no-cache, must-revalidate" attributes in the Cache-Control header for that cached page, then that visitor's browser will not fetch anything from your server, and will continue to use its old cached copy until it expires or is replaced in the cache by a page or object from another visited site.
Taking into consideration the constantly-declining benefit of increased cache expiry times, and the fact that it is the browser and not your server that determines whether a page will be re-fetched, setting expiry times of more than two weeks or a month is not useful and constitutes a 'liability' for you if you need to update a page.
Since it is to hard to predict the "perfect" cache settings, I'll just give you an example from one site:
Most HTML pages are cached for eight hours.
Critical and frequently-changing HTML pages are cached for one hour, and have the "no-cache, must-revalidate" attribute set. (Note that due to legacy issues, "no-cache" does not mean "don't cache." It now means "I said must-revalidate, and I mean it.")
Error pages are non-cacheable.
Images, documents (e.g. PDF), and media (swf, flv, avi, wmv, mp3) are cached for two weeks.
JavaScript and CSS files are cached for eight hours.
The appropriate caching policy for any given request is selected by enclosing the "Expires" and "Header set" directives for each of the above-described groups within <Files> and <FilesMatch> containers.
In "emergencies" where any of the non-revalidated object types must be changed immediately, I change the URL of the object. Since objects are cached based on their URL this forces them to be reloaded, by-passing the previously-cached-object problem.
Jim
