I think sundialsvc4 should presume to speak for all applications. The only core module we've got to serialize data structures is non transportable and therefore undependable. Core modules shouldn't be a gamble.

I've been burned myself by 'fozen' data that wouldn't thaw after being transfered to another machine with a different version of Storable. A simple perl update could leave you with a database of unusable data, or a backup file that can no longer be recovered, or in my case it was a move to another server (with a different versions of everything). I'm not going to risk my application like that (again).

So having learned by lesson I avoid Storable like the plague. Now I 'freeze' data with Data::Dumper (which is core) and 'thaw' with eval. It's messy and awkward and I'm sure no where near as efficient as free/thaw but at least the serialized result is guaranteed to be readable by any version of Perl on any system the data may end up on (or moved to).

Before it was ever introduced to core, Storable should have been prepared for a future of new features and formats. From the very first 'version change' it should have been purposely defaulted to the most basic universally recognized serialized data format (first version) with caveats to programmers wishing to take advantage of newer features. I would be using it today if I could expect consistent behaviour between versions but as it is I can't rely on it and I can't recommend it. The genie is out of the bottle, you can't fix Storable now.

Storable has too high a price to pay for anything but fleetingly temporary data. In other words, data that probably shouldn't be 'stored' in the first place. In my books that makes the module a complete fail for the purpose it is (generally) expected to serve.