I've started using it in 2009. I am still using it in my projects, but I am still not sure if NHibernate is functional complete or if the project is nearly dead.
It works fine for me (if it is not worth the effort I am using Dapper.net), but it doesn't seem that there is much active development going on.
I started a project about 4yrs ago, it was EF vs NH. Went with NH because EF was still pretty immature.
The momentum is pretty clearly toward EF IMO. NH is missing a lot, including proper migration tooling and deep async support. But I don't think that's the real issue. The more foundational problem in my view, is that NH deeply assumes blocking/synchronous database access. I have no idea how NH lazy loading will ever work with async. I imagine you'll have a bunch of FK refs all marked Task<T> that will have to be awaited? In any case, my bet is that EF will get there a lot more quickly than NH.
I stopped working on nhibernate around 2010-2011, when i started masters. I did only keep in touch with one friend - i am not very sociable person. So I guess short answer is, i am not sure to be honest.
Back in 2008ish, I was thinking it was going to die because Entity framework provided a great support for linq, and it had a great hype. A bunch of enterprises moved away from NHibernate (we also had a lot of legacy from XML configuration - a bunch of internal data structures were referencing xml), so it was clunky. Fabio, Oren (Ayende) did a bunch of improvements, I worked a bunch of shortening initialization times and so on. I think Ayende did a very good job with Linq initially, but there were plenty of edge cases that i remember having to fix :) It was my first opensource project as a core member (second and last was castle project) - so it has a very special place for me :)
I've used the Linq queries in one of my projects, but I like the QueryOver statements more (a little bit too much black magic in the Linq queries).
But I believe that it was a great effort - so let me thank you for that !
Linq with the EF is great for simple queries and updates, anything else and you're in for serious performance problems as soon as the app scales. Better to drop to normal SQL for complicated data loading.
Even MS can't write decent LINQ queries, their ASP.Net identity provider is now the most 'expensive' bit of our app now because they used expensive LINQ queries instead of using raw SQL queries. Admittedly our use-case is abnormal as the specific problem we have is that because of the way users are added their password gets reset almost immediately, as they're invited by an organiser. It also means new users are constantly being added. When the password reset is saved it completely unnecessarily "verifies" the update by making sure the username and email are unique, which means two UPPER()s and CONTAINS()s on string fields. Unlike the old provider there's no usernamelowered field already in the db to avoid this.
We can fix it by over-riding these queries, but it's annoying that the ASP.Net team took a core framework piece that was very performant with fast performing SQL and made it substandard. At least I can look at the code now ;).
I think LINQ gets a lot of flak it doesn't necessarily deserve in complex queries due to people stopping at the black box and assuming black magic. It's a very functional programming paradigm embedded in an otherwise procedural world, and so the skills to debug complex LINQ should be unsurprisingly just a bit different than debugging most else in C#. I don't blame people for stopping at the black box. I just think more people should know that you can do more than stop at the black box.
(Also, it amuses me that your example from ASP.NET identity's changes have nothing to with that it should be using raw SQL queries versus LINQ, and everything to do with denormalization versus the query execution engine. It shouldn't be a huge surprise that Microsoft might trust SQL Server to be able to UPPER() and CONTAINS() fast enough, and the queries rare enough that it isn't necessary to denormalize that information.)