The changes have been committed as far as I can see and refused with absurd explanation IMHO, but check yourself, it's only my opinion.
What I know for sure, because it's public, is that AirVPN forked only after a long (harsh?) public debate on the commits with the main branch maintainer.
I can see bug fixes summarized in the changelog, look at "Changelog 3.3.2 AirVPN - Release date: 10 October 2019". Then look at the fixes in the code: the AirVPN developers are indeed right as far as I can see, without those fixes the library could have never worked (and the main branch still does not work!) in Linux.
I wonder whether AirVPN would have forked were those commits accepted. Surely they forked only after some time the commits were there, available, as a precious gift IMHO, but still refused without any serious analysis.
I don't agree, but I don't want to act as an outstanding coder. I don't even want to defend AirVPN developers because their software "Eddie" for Linux is ugly, IMHO, and I say it as an AirVPN customer too. But hey I hate Mono. :)
But the OpenVPN 3 fork and Hummingbird too appear to me as good, very good. The fork is well organized, the new parts are quite elegantly coded at least to me, very readable and well commented, and it's kept ahead in alignment with the main branch. Some time ago I also followed AirVPN commits to the main branch and after I took my time to watch the code I was astonished that they were rejected with some arguments that, I think, are either pretentious or wrong, but that's an opinion of mine, the facts can be seen by anyone looking at the code and some smart solutions/implementations I find delicious such as pointers to methods to optimize and save time in packets cipher dependent decisions. I wonder... if the initial commits to the main branch were not rejected, would AirVPN have forked? They forked only after a long debate... I don't know but...
Most (all nowadays?) Android tablets and smart phones are based on ARM processors that do not support AES-NI. Even a lot of consumers' routers, which can run OpenVPN, do not support AES-NI.
Raspberry Pi, nVidia Shield, Amazon FireStick are additional examples that come to mind, not to mention many other embedded devices, mediaplayers, Android based TVs...
I have verified impressive improvement (up to 45%) in throughput with CHACHA20 vs. AES-256 in several ARM based devices running either Android or Linux ARM (connecting to the same AirVPN server with same router, same ISP and same application based for Android or Linux ARM on their forked library).
About desktop computers, things might change with AVX-512 wider adoption: it remains to be seen whether AES-NI can perform better with AES-256-GCM than AVX-512 supporting processors can do with CHACHA20. I don't have the option to test that, anybody did?
What I know for sure, because it's public, is that AirVPN forked only after a long (harsh?) public debate on the commits with the main branch maintainer.
I can see bug fixes summarized in the changelog, look at "Changelog 3.3.2 AirVPN - Release date: 10 October 2019". Then look at the fixes in the code: the AirVPN developers are indeed right as far as I can see, without those fixes the library could have never worked (and the main branch still does not work!) in Linux.
I wonder whether AirVPN would have forked were those commits accepted. Surely they forked only after some time the commits were there, available, as a precious gift IMHO, but still refused without any serious analysis.