While the semantics are indeed debatable, I'm afraid there is no easy way out of it: Parent/child merging happens at a later point within the factory itself, since parent bean definitions may be declared in other files or even other configuration formats... So when parsing a particular XML bean definition file, all we can do is to apply the defaults as declared in that file, just like if the init/destroy method was locally declared on each bean element. I'm afraid you simply shouldn't try to mix and match default declarations with parent/child inheritance there.
That said, I discovered an inconsistency in our handling between init methods and destroy methods: While the overriding of default declarations works through empty String values for init and destroy methods, the same only works for destroy methods in a parent/child inheritance scenario. There's no good reason why this shouldn't work the same for init methods, so I'm adding that for 5.0 RC4 now, repurposing this improvement request towards that. While this may not be what you were aiming for, it's at least consistent in its semantics across all scenarios now.