A Setting Is a Request, Not a Fact
Flip the toggle on a blog from excerpts to full-text feeds, hit save, refresh the RSS reader. Nothing changes for the posts already out there. Every entry published before the flip still ships as a three-line stub, because the feed isn't regenerated when the setting changes, it's regenerated when a post is saved. The setting took effect immediately and did nothing immediately, both true at once, and the gap between them sits there until someone happens to edit an old post and the full text finally appears, as a side effect of an unrelated action, months later, for no reason the reader could guess at.
That's the general shape, not a WordPress quirk. A setting is almost never a live description of what the system is doing. It's a value stored somewhere, pointed at the future, waiting for the next event that happens to read it. The artifact, the page, the cache entry, the row, the running process, was built under the old value and keeps being that artifact until something forces it to be rebuilt. Nothing in between checks whether the two still agree.
Feature flags do this. A flag flips in the admin panel; the five worker processes that already loaded the old value into memory keep running the old code path until they restart, which might be on deploy, might be on a crash, might be next Tuesday. A CDN cache TTL gets changed from one hour to one week; every object cached before the change still expires on the old clock, because the TTL that matters was captured at cache-write time, not read fresh on every serve. A database column gets a new default value; every row inserted before that migration keeps its old default forever, because defaults apply to inserts, not to history. None of these are bugs. Each one is the correct, efficient behavior for the common case, apply new settings going forward, don't pay to rewrite everything that already exists.
What's missing in all of them is a flag for the divergence itself. The settings page says "full text." The feed says "excerpt." Nothing compares those two and says so. There's no dirty bit on the cached page that lights up when the TTL config no longer matches the TTL it was written under. The row with the stale default looks exactly like a row that was deliberately set that way on purpose; the database has no column for "this value is wrong because of a decision made after I was written." The information needed to detect the gap exists in two separate places, the request and the artifact, and the system was never built to hold them side by side.
The honest way to think about a setting, then, isn't "the current state of this option" but "the last thing anyone asked for, applied going forward from whenever it gets read next." That reframing changes what you'd actually want to build if you cared about closing the gap: not a smarter default, but a job whose only purpose is to walk the artifacts and check them against the current request, surfacing the ones that never got the memo. Almost nobody builds that job, because it only pays off on the rare case, and the rare case doesn't show up in a changelog. It shows up as a support ticket from someone who swears they changed the setting weeks ago and can't understand why the thing in front of them still looks old.
Which is the actual failure mode worth naming: not that settings lag, everyone who's worked with a cache already expects that, but that the lag is invisible by default, indistinguishable from correctness until someone goes looking. The setting isn't lying. It's just describing a future that the artifact hasn't been told about yet.