If a developer marks a configuration element in their node with @Password, even if the field itself is marked Optional<char> or Optional<String> node processing will fail. Additionally, the XUI will incorrectly mark the field as requiring input the first time the page is loaded. It will then 'forget' the submitted data if the node is saved.
Saving the node will be allowed (as the server does not perform any validation on the optional field), and the message will disappear after the first save of the node.
The XUI editor should not mark such nodes as required unless the field is not Optional and the RequiredValueValidator is applied to it. Additionally, there should be functionality to allow for masked (@password) fields to be Optional while also operating in a secure fashion (using char rather than String directly to avoid potential interning issues).
After further investigation, this appears to be an issue caused by the OptionalTypeAdapter not playing nice with the PasswordTypeAdapter. The latter returns type char, the former Optional<?>, however the code flow currently wants to return a type of Optional, and casts the returned type to it, which explodes. PasswordTypeAdapter and OptionalTypeAdapter will have to learn how to play nice if we want to support optional password fields.