First, mind that I only express my point of view. Moreover, I am member of NHibernate team only since a few days. As I have said, others are working on async. And I am not arguing against it. I am just expressing my view, considering this feature is not critical.

Supporting functionalities of .Net is better of course, but not a must.

Strongly wanting async in NHibernate looks to me as a sign of not knowing how to leverage some of its feature, like efficient lazy loading and second level cache (which can drastically reduces IO, while async somewhat just allows more IO to run in parallel).
This especially:

If performance is demanded, eager load is the way advanced developers will take

Hum... Read this comment from a NHbernate gold tagged user of Stack Overflow and this detailed explanation on why preferring lazy loads other eager loads with NHibernate.
I do not say there is no valid usage of eager loading, but I strongly disagree with believing "advanced developers" should use eager loading for "performance". If you believe there are no way to avoid the N+1 loading trouble with lazy loading, please read above links. And there are other advantages of lazy loads written in those links.

I maintain lazy loading does not play well with async: when it triggers a load, it is a blocking IO. Going async is about avoiding blocking IO. If an application is in a case of thread starvation due to blocking IO, going async while keeping lazy loads would not relax the issue much.

async is a tool for a specific class of performances issues, and not the unique tool for it (second level cache, load-balancing among servers, reducing IO delays, ...). It has advantages and drawbacks. I believe it is a nice to have, not a must have.

Why a point about honoring eager loading from mapping in Linq queries? This is unrelated. It would be a convenience for those wanting to always eager load some relations with Linq. But it would be a breaking change for all those wanting to load them only on explicit fetches call on the Linq query. (Aligning with EF does not look as a target for me. Otherwise I would PR NH features missing in EF into EF and cease using NH.)

Crowdfunding? This would mean hire some developers, manage them, ... NHibernate is volunteered based, there is no NHibernate company. I would be surprised if other volunteers of NHibernate would want to go that way.

The best way to speed up things is to contribute IMO. Linked issues link to some pull requests. Better start with small prerequisite and non breaking changes, discuss with people who have shown interest in the feature, ...

Actually what you refer to as "covering features of others ORM does not look as a priority to me" is a functionality in C# and a way to create more scalable apps.

Btw: while doing a Linq async query, i don't see the place where lazy loading could occur - IMHO lazy loading plays a role after your Linq query (with eager load) finished asynch execution and a result (entity/entities - with proxies) is returned

Hmm, if you had in your mind to support async for lazy load as well, then I doubt such a fnc. is in EF, and I neither think this function is important. If performance is demanded, eager load is the way advanced developers will take. So for performance 2 things are missing:

• async linq queries

• supporting eager load settings (from mapping) while using linq [actually this would make NH more compatible with linq which is a standard in EF and would give us other additional benefits NH has over EF]

I accept that this is a duplicate, thank you for adding the support async into the title.

Btw: what do you think, would crowdfunding help to speed up things?

Well, EF has also a complete Linq support, while NH does not support all constructs. EF avoids Cartesian products when performing multiple eager fetches of collections, and supports pagination with eager fetches of collections. I am sure we can find some other features. But that is not the point, covering features of others ORM does not look as a priority to me. Having a coherent and useful features set come first in my opinion.

About async, this may come, some contributors think about it (see by example). Some preparatory works have been done (like NH-3431).

Now NHibernate works very well with lazy-loading thanks to lazy-loads batching, while not being very good at eager fetches. Taking advantages of async would require either banning lazy loading or elaborating a pattern allowing async lazy loads (which would probably imply using some helper everywhere for awaiting access to lazy properties).

I close this issue as a duplicate of NH-3905.