Far too late to edit now but I'd note that Future::AsyncAwait is implemented using only public APIs - it adds the keywords using the pluggable keyword API that was added in 5.14 and 5.16 (though while code written against the 5.14 version continues to work AFAIK given we're on verion 38 of perl5 now I wouldn't bother even looking at it except out of historical curiosity).
So, basically, adding new keywords to perl via CPAN is a first class citizen and has been for over a decade now and we've gotten pretty good at it in that time (see also http://p3rl.org/Object::Pad - which has acted as a proving ground for a lot of the ideas that have gone into Cor - for another good example) and while I wouldn't at all object to F::AA eventually migrating into being a core feature, from a user POV it would just mean a slightly different 'use' line and maybe a few percentage points' speedup.
As such, I personally believe that while I understand that some environments have unfortunate issues with having dependencies, every other reason I've heard articulated for treating a keyword module as an inferior bolt-on as compared to a core keyword has proven unsupported in actual use.
Generally I code to (a) core perl only, mostly for one-liners embedded in shell scripts and occasionally for really small stuff, (b) pure perl dependencies only so I can easily deploy a single file with App::FatPacker or no file at all with Object::Remote, and (c) this project is best done using XS stuff and I'm willing to accept the trade-offs.
I'd note that Future::AsyncAwait itself sits in an interesting middle-ground because with a little help from my http://p3rl.org/Babble source transformer (needs more documentation though the current release manager has improved a lot of things over the 'just enough to do what I needed at the time' I originally released) I wrote http://p3rl.org/PerlX::AsyncAwait which rewrites most F::AA using code successfully to pure perl for fatpacking, at the cost of you ending up with an implementation that's mildly bizarre at first look and will be substantially slower on microbenchmarks.
(I say 'most' because I presume there's at least one bug and I'm certain that F::AA has added support for additional perl syntax constructs since that I've not gotten around to going back and adding yet, but so far in the situations where I want a fatpacked async/await using script badly enough PerlX::AsyncAwait has worked well -enough- overall that I've yet to feel the need to give it an overhaul even if I'm happy to admit it would probably benefit from one)
So, basically, adding new keywords to perl via CPAN is a first class citizen and has been for over a decade now and we've gotten pretty good at it in that time (see also http://p3rl.org/Object::Pad - which has acted as a proving ground for a lot of the ideas that have gone into Cor - for another good example) and while I wouldn't at all object to F::AA eventually migrating into being a core feature, from a user POV it would just mean a slightly different 'use' line and maybe a few percentage points' speedup.
As such, I personally believe that while I understand that some environments have unfortunate issues with having dependencies, every other reason I've heard articulated for treating a keyword module as an inferior bolt-on as compared to a core keyword has proven unsupported in actual use.
Generally I code to (a) core perl only, mostly for one-liners embedded in shell scripts and occasionally for really small stuff, (b) pure perl dependencies only so I can easily deploy a single file with App::FatPacker or no file at all with Object::Remote, and (c) this project is best done using XS stuff and I'm willing to accept the trade-offs.
I'd note that Future::AsyncAwait itself sits in an interesting middle-ground because with a little help from my http://p3rl.org/Babble source transformer (needs more documentation though the current release manager has improved a lot of things over the 'just enough to do what I needed at the time' I originally released) I wrote http://p3rl.org/PerlX::AsyncAwait which rewrites most F::AA using code successfully to pure perl for fatpacking, at the cost of you ending up with an implementation that's mildly bizarre at first look and will be substantially slower on microbenchmarks.
(I say 'most' because I presume there's at least one bug and I'm certain that F::AA has added support for additional perl syntax constructs since that I've not gotten around to going back and adding yet, but so far in the situations where I want a fatpacked async/await using script badly enough PerlX::AsyncAwait has worked well -enough- overall that I've yet to feel the need to give it an overhaul even if I'm happy to admit it would probably benefit from one)