Currently, reverse engineering just updates hibernate.cfg.xml with those settings that it knows about and leaves the rest alone. This has two drawbacks:

• The information about database structure is scattered across two files, namely hibernate.reveng.xml and and hibernate.cfg.xml.

• When editing hibernate.cfg.xml, it's not instantly clear which parts of the configuration will be overwritten by the next reverse engineering run and which will persist.

For this reason, I'd like to suggest adding a mechanism to reveng.hibernate.xml that allows specifying arbitrary XML tags and attributes to be copied over to hibernate.cfg.xml. (One example might be a <cfg> tag that has its contents copied over to hibernate.cfg.xml.)
To make sure that no unwanted information in hibernate.cfg.xml survives, one could either add a new <purge-cfg> tag with a yes/no choice to decide whether hibernate.cfg.xml should be rewritten from scratch or retained. (It may make sense to implement a more fine-grained control over what to purge and what to keep. That might solve #HBX-1046.)

In an environment where the database model is the leading data model and the Java code has to follow, this would allow validating Java applications against database changes: do another round of reverse engineering and fix the Java compiler errors.
This is not a complete solution since changes in field widths and constraints won't stick out, but it would already be helpful.