Back in November, a patch was merged to use the system temporary directory in the event that $wgLocalisationCacheConf['store'] was set to 'detect' (the default) and $wgCacheDirectory was falsey (also the default). This has the effect of making it so that the default values will never cache to database on any sane server configuration.

There are a number of challenges of doing this that make such a fallback less-than-ideal, to the point where we may want to revisit if this fallback should exist:

1. /tmp is cleared on reboot, and there may be crons to clean it at a regular basis, obviating the performance benefit of storing the cache on-disk due to needing to regenerate it all the time.
2. Space constraints -- /tmp may not be large enough to store up to 1GB of cache files in addition to all the other stuff typically stored there (see Krinkle's comment in the linked changeset for how one would get this up to 1GB).
3. Multiple wikis -- The cache is unique per-wiki however the default configuration now means that either wikis will be trying to load the wrong caches, or will fail spectacularly when they try to write their own cache files and can't due to all of them trying to use the same filenames under a default configuration.

I'd argue point 3 is the most important one here, as it is a hidden gotcha in setting up multiple wikis on the same server. One must be prescient of this fact and needs to configure the wiki to not use the defaults in order to avoid this. This impacts not only wiki farms (where a user aware to this fact could plan around it by changing configs), but also shared hosting scenarios where individual users would not know to change the config in order for their wiki to work.

I see two plans of action going forward:

1. Revert that change. This will bring a performance hit to default configurations due to now using the db instead of the filesystem (how much and is it worth it?)
2. Modify the fallback so that the filenames it caches to are somehow unique per wiki instance (e.g. somehow keyed on wiki id, which should be unique even in a shared hosting scenario). Also, we should remove the 'detect' store (making it an alias for 'files' for b/c purposes) and update our documentation, since right now it's impossible for detect to default to db outside of strange/broken configurations (namely setting $wgTmpDirectory to "").

Cc'ing @ori since he was the author of the patch in question.