Adding a getter to retrieve a previous decorator doesn't actually make a whole lot of sense to me.
Consider that the intent of a decorator is to add behaviour dynamically to an instance of some type (class or interface), and that instance can be decorated multiple times. How are you ever supposed to know which decorator reference - or indeed a reference to the original undecorated instance - will be returned. It's completely dependent on the order in which the decorators were applied. Further more, if you are strictly programming to an interface, all you'll have available to you is the interface of the orginal undecorated type. Which would need to specify a getter that returns an instance of itself, soley for the purpose of obtaining a previous decorator reference - something it shouldn't have any knowledge about in the first place. This seems odd to me. Come to think of it, I don't think I've ever encountered a decorator implementation that allowed for this kind of unwrapping behaviour, and I'm struggling to come up with a use case for it.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.