Since WordPress 2.8, a new kind of caching mechanism has been added to WordPress. it is not very well documented yet (I could not find any relevant page in the Codex. Please leave a comment if you find one).
According to this WordPress core development trac discussion, that feature has been introduced so that “non-persistent” or otherwise “short-lived” data that used to be stored in the “options” database table can be distinguished from “real options data” that is meant to be persistent (ie, live forever in the database until it is updated or erased). This way, specific cache implementation plugins can implement optimized behaviours for each distinct type of data storage (by using in-memory mass storage solutions for example).
This WPTavern forum post from Otto about when to use cache and when to use options for storage explains the right way to implement things for an RSS-fetching cache; it makes for useful reading. The transient mechanism has been implemented for all RSS-related features and for Rewriterules since WP 2.8.
For now, by default, if you do not use any specific caching extension (such as the WP Super Cache plugin for example), transient objects will continue to be cached in the options database table. So apart from noticing the new _transient_ option_name keys, not much will change in basic WordPress blog setups. Things do change a lot for advanced cache-enabled setups, as can be seen in RSS caching behaviours.
New RSS feed caching implementation
For RSS, you can see the changes in the wp-includes/rss.php core file: what used to be stored as regular options in the MagpieRSS cache functions is now setup as transient objects with a fixed expire date. That means you won’t be sure to find the stored RSS feeds in the options table anymore if you use any advanced cache plugin. It also means that outdated feeds data “disappears” altogether after the expiration date: this can somewhat change the behaviour of RSS-manipulation extensions or plugins (it changed a lot of things for me…), for example, you cannot count on displaying outdated RSS information to your visitors while you go refresh the cache in the background. In my case this means I’ll have to make sure in advance that important RSS feeds are refreshed on a regular basis before meeting the expiration date. (note that the “STALE” delay of twelve hours is still hard-coded in the Magpie class, so I guess that can’t be used, especially when the default CACHE_AGE seems to be set at one hour).
By the way, another big change in the WordPress RSS implementation is the use of the new (since WordPress 2.7) “uniform HTTP request API” as discussed here, instead of the old Snoopy class. That’s an important improvement (but it’s another story). That new API is to be found in the core wp-includes/http.php file.
The transient functions are somewhat documented in the core wp-includes/functions.php library file. The bottom line is that the new transient filter and hooks make it possible to implement interesting RAM-caching and otherwise optimized-persistance schemes. One should however be conscious that transients are no regular “old fashioned” options: there’s no guarantee you’ll find them in the database at all, and you won’t find them anywhere once they’ve expired (well… that’s what expiration was meant for in the first place, wasn’t it?)