> where we stopped

We stopped at pre-historic (pre-git) times of Hibernate

Following up looks to me complicated by the JPA standardization. JPA acknowledge the success of ORMs and defines a common interface for them, mainly derived from Hibernate. Until recently Hibernate was implementing JPA with separated modules (like this), but they have started merging it in the core. (HHH-10664)

JPA is neither a subset or a super-set of Hibernate, so they maintain both Hibernate "native" interface and JPA interface, both being now mixed, with only comments for telling which methods are native, which are JPA, which are both.

I tend to think NHibernate would not benefit much of implementing JPA since probably no other .Net ORM is going to implement this Java specification. So now when porting, we have to take care not introducing unneeded JPA interfaces.

And by doing HHH-10664, they also seems to carry on some refactoring (such as reducing the number of session constructor parameters from 10 (current NHibernate) to 2 (current Hibernate).
I was getting ready for realigning connection/transaction management in session on Hibernate, and trying to do it from their current code base, porting this constructor refactoring was looking to me as a prerequisite. So I have searched for its HHH issue, only to discover it has been done with the JPA merging.

So maybe instead of trying to "short-circuit" history directly to latest implementation should I instead try to follow up incrementally from "where we stopped", but I fear that in the end it would be way more work. (Need to identify where we stop for those subjects, by the way.)

I intend to carry on that refactoring, not as an exact port due to above issues, but at least realigning the design principles. And see if it looks workable that way.

Any thoughts welcome.