Yes, very important. I store the sensitive value Inside-Out, and incompatilibity with data serialization tools is one of the classic (dis)advantages of inside-out objects. The serializer simply can not access the sensitive data since the sensitive value is stored in a lexical variable in the Text::Hidden package.

Since debugging is often done with these serialization tools, in future versions I intend to try to serialize as smartly as possible: make it clear in the serialized output that the value has been masked; warn or die if a de-serialized object is used. Of course, I can only support the most popular serializers, but even those which will not have built-in support will not be able to access the sensitive value - even if they dump code references.

Regarding length of the value: Yes, I had waffled on that for a bit but for debugging purposes (detecting the empty string) went with length for now since overriding the obfuscated value to be a fixed string is easy. I will probably make the default a bit more safe/smart and even more debug-friendly in the next version. My plan now is to return: "«empty»" | "«undef»" | "XXXXX" (fixed length) as appropriate from the default obfuscator.