Das Argument "im Core enthalten" hat Linuxer schon gebracht, das spricht für Storable.

Für das Kleingedruckte kommt es darauf an, was in der Perl data structure drin sein kann. Wenn es nur Zahlen, Zeichenketten und weitere Referenzen auf Hashes und Arrays sind, gibt es keine Probleme. Auf unterschiedlich unterhaltsame Art und Weise kann man scheitern, wenn einer der Werte blessed ist.

Storable ist ja vor allem für Serialisierung gedacht und geht beim Klonen über einen Freeze/Thaw-Zyklus. Es ist etwas "defensiver", was in den Daten drin sein darf, weil es unterstützen will, dass die serialisierte Daten auch mit einer anderen Perl-Version wieder interpretiert werden können. Deswegen verweigert Storable beispielsweise Code-Referenzen, obwohl sich das Problem "andere Perl-Version" beim Klonen gar nicht stellt.

Objekte, bei denen ein "generisches" Klonen problematisch ist, sind solche mit XS-Komponenten (oft als Skalar-Referenzen implementiert), die ihre Daten in einer C-Struktur an den "Magic"-Pointer der Variablen dranhängen.

Die neuen Objekte mit use feature 'class' lassen sich noch gar nicht klonen. Wenn man sich diesen neuen Objekten mit Feature::Compat::Class annähert, dann funktioniert das Klonen... bis einschließlich Perl 5.36, denn bis dahin wird mit Object::Pad gearbeitet.