Doing a few runs with it tonight I can say two things.
I do NOT consider an AUR helper that crashes out if you answer No on an option where No is a valid option “Stable”
It is slightly faster than Yay, probably because Rust. However again Yay definitely seems more mature, in all the good ways.
Always double check your sources on the internet. -Abraham Lincoln
Yay is still maintained and will keep receiving updates (ex: pacman 6 support).
I am more focused on making the interfaces on yay more stable and developer friendly, of testing components to avoid them breaking between fixes, checking for bottlenecks. In terms of feature amount you may want to try Paru, Morganamilo has a lot of experience and wisdom on the subject.
This last year has been atypical which also hasn’t allowed me to dedicate as much time as I wanted to yay but expect this maintainability focus (as opposed to feature focus) to last at least until summer.
After doing some tests tonight with an actual try to configure paru as I like it, not just a try-once, I will stick with yay for now.
ah wel when you see on the southpole, when a pinguin jumps intoo the water, rest follows 
All except … one …
I looked at it, it’s really more informative than yay.
One advantage of paru compared to yay:
today I needed a working "–assume-installed " option. Both knows it. Yay is ignoring it, paru is working with it. I like yay much. But only bug fixing and not finishing started features will rank it down more and more. Not important today, and you can use both simultaneously…
you can use any helper 
Most importand piece of function the helper must work is working with pgp properly not al helpers does works properly.
rest is sidestory
Linux sometimes you have time you work to a level but as with corona in his case, it comes bit to a stop or other stuf around. is not strange. Paru might booming offcourse but moment of life it going down a bit then you go to maintainance mode… surely i added a bugfix about --editmenu but it wasn’t in my taste fixed properly, but the treath got closed… is about depency stuf etc… but i use personally mostly other helper, paru is for playing but have atleast 4 installed 
(bloated as speak) but mostly use pakku also i find it wonderfull but pitty nobody takes it over properly it get safed in times but is slacking on that way worser then yay does 
even yay in maintainance it get worked on it.
Where do you get that from? It’s oddly specific.
Do not fall for the story about yay no longer being developed. It is a fabrication by a salty ex-developer of yay. Development of yay is still active, and it gets regularly updated.
In my opinion, the only downside to yay is that it is soyftware written in Go. It’s a terrible choice for a programming language. But other than that, yay is awesome.
That’s actually the only reason why i started to think about trying paru…
Rust 
Nice day for yay!
It maybe oddly specific, but I am not the only one who need this. And paru helped me to install sdrangel-git on arch Raspberry Pi. Dependency “qcustomplot” which is not available on armv7h prevents installation with yay. Using paru it works flawlessly - only the specific function which uses qcustomplot does not work of course - but I do not need it. This bug was listed in GitHub Dec 2019: https://github.com/Jguer/yay/issues/1137 and was confirmed. Google gave me the hint to try paru because of this issue report, and it worked for me, too.
Do not misunderstand: I like yay much and I will not leave it. But the bug related to --assume-installed makes it neccessary for me to use paru, too…
Only what get me is some misinformation also spread on youtube. Sure like edit-menu is in paru removed so some bugs hanging in yay paru fixed sure things are going on that part but since we use yay you can find loads od helpers.
Well, the use of an AUR helper is never necessary. You can just makepkg -si yourself. 
I like yay though i may not understand package build process. I use it a lot.
Alternatively, you could use yay --editmenu and just remove the dependency.
In your very specific case, you could also install a dummy package so it would show as installed which would make updates smoother.
I by myself can build packages “from the scratch”. But I am the initiator of a local linux interest group (https://suletuxe.de) and most newcomers are heaviliy overwhelmed with such processes. They like (and want) helpers like yay. But some of them are very involved in science and want to install specific software. It is a pity that a simple option does not walk into yay since 2019. But we should not discuss: all energy that goes into such projects is without commercial intendents. So I am suggesting to use paru if someone steps into an issue that wants “–assume-installed” and normally use yay. Maybe the users see that paru is able to do everything that can yay do AND additionally has some benefits - so some will switch to paru.
Just a note - I don’t think yay does anything useful with --editmenu. It works out dependencies BEFORE checking the results of editmenu! Kept me using yaourt for a while, before just using makepkg -si directly. I wonder if paru fixed that, I suspect (remember?) it did…
That is what I mean. We should not make a “war of believing”, we should look at the facts. Nobody wants to bother any developer or maintainer. At my specific sdrangel problem the installation is cancelled BEFORE I get the menu for editing. That is pointing in the direction @freebird54 stated.