We are migrating a JEE application that works in production from Kodo to Hibernate.
We don't want to use proxy mechanism because our system is not suitable for that and we don't want to rewrite such a large part of our business layer logic neither use eager fetching (which worked perfectly fine for us but very very slow).
So, we decided to use bytecode enhancement. We used Hibernate 5.2.11 and switched to bytecode enhancement as in the attached test case.

The problem is that we encountered some NullPointerExceptions in our bussiness layer and after some days of analysis it turned out that these nulls are in database too but they shouldn't. What I found is that they are caused by Hibernate mechanism which nullifies all transient properties in org.hibernate.engine.spi.ActionQueue#addInsertAction
It calls in the end org.hibernate.engine.internal.AbstractEntityEntry#isNullifiable
and then our property is nullified because of the first condition if ( getStatus() == Status.SAVING )
The property is in the SAVING status because it was once cascaded and it cascaded other entites which in turn cascaded the one that leads to the method org.hibernate.engine.spi.ActionQueue#addInsertAction I have mentioned above.

Notice that I have not encountered this problem using proxy mechanism with eager fetching on every to-one association, so this must be connected with bytecode enhancement and that's why I post it here as a bug.
I have been trying for a few days to provide a testcase reproducing the issue but I found it so difficult that I gave up. I am attaching what I managed to do. Running it in a normal way doesn't trigger the bug but if you debug and put a breakpoint in org.hibernate.engine.internal.Cascade#cascadeAssociation on the first condition (line 382) and just let it continue every time it stops there, the output is different and shows the issue (I used IntelliJ IDEA built-in debugger). I provided printed SQL logs for both run and debug 'modes'. I asked about it here:
https://forum.hibernate.org/viewtopic.php?f=1&t=1044908

I am sorry but we can't show you the issue in our system because it is forbidden to publish its source code, so the classes are simplified a lot and the classes names in the attached testcase are changed (the names are not very suitable, sorry for that).

I am aware that CascadeType.PERSIST on every @ManyToOne is not a good practice, but with Kodo we used a persistence-by-reachability concept with deferred constraints mechanism and we found that this is the only way we could do this with Hibernate (we may be wrong though).
testcase-debug-sql.log testcase-run-sql.log BytecodeEnhancement-Nullify-TestCase.zip

Please consider the issue and if you have any idea give us some advice or workaround. We got deep into Hibernate internals analyzing this issue but we still don't know enough about the Hibernate to understand this very complex problem.