This data is checked carefully on input and output. When undef gets somehow into hash then error is thrown.

Ok, I see. Although of course there are exceptions, I find it easiest to work with hashes in one of two ways: either a fixed set of possible keys, in which case one can avoid autovivification issues by not differentiating between exists and defined, so it doesn't matter whether a key is present or not, and undef simply indicates "no value". Or, the other situation is a set of keys that is unknown to the code beforehand, in which case one generally only iterates over the hash with keys etc., and one doesn't generally access specific hash keys by name.

It sounds like you might be mixing these two - although there are sometimes valid cases where a hash has a known set of keys and one does want to differentiate between exists and defined, I've found this to be a little annoying to work with. For example, in my module IPC::Run3::Shell, there are options that can be exists but not defined, but then there is no easy way to override these options so they no longer exist in the hash.

Anyway, In the code you showed, I might have gone with exists checks to prevent autoviv, even if that makes the code more verbose.