I respectfully disagree. For beginners Module::Starter is way more easy to comprehend!

My other grunch with Yet Another Authoring Tool is that you will seriously raise the bar for external contributors that do not have that tool (or any of the zillion available plug-ins) available nor have the experience with that tool nor the time to read their docs.

IMHO one should have a seriously good reason to go beyond Makefile.PL (optionally generated from Module::Starter).

I see myself as a well-seasoned perl programmer, and being confronted with releases that use Build.PL, dzil or whatever non-standard tool, will chase me away if it is not absolutely required for me to participate.

Okay.

I can't help ya if a Build.PL file makes you break out in hives 20+ years after they were introduced but do you honestly think a beginner would have a hard time comprehending

minil new My::Module
cd My-Module
# ...tinker
minil release
[download]

but having no issue doing (less) with

module-starter --module=My::Module --email=them@cpan.org --builder=Mod
+ule::Build --genlicense --ignores=git
cd My-Module
git init .
git add .gitignore
git add *
perl Build.PL
# ...tinker
./Build disttest
./Build dist
# ... manually upload dist to PAUSE
git commit -m "Here we go"
git tag -m "v1.0.0"
git push origin v1.0.0
[download]

Both create the same basic layout of a perl dist: the build script, lib/Fun/Module.pm, a basic test in t/, the initial changelog, etc. But Minilla also inits a git repo (opinionated, but having a repository is standard best practices regardless of language), introduces modern, organized dependency declaration by creating a cpanfile (which is understood by cpanminus), introduces the hypothetical beginner to CI by generating the Github Actions workflow I mentioned earlier, and creates a markdown README which just plain presents itself better on the web than M::S's text based one because GitHub will automatically display the markdown file on the repo's homepage. There's no messing around with the MANIFEST by hand or fiddling with how the dist gets to PAUSE every release. Without touching a config file, a brand new dev using Minilla is already off to a smooth start, in a better position to find issues before uploading to PAUSE, and none of it makes their released code any more difficult for you to install.

And when they decide to release their code, if the optional modules are installed on the author's side, Minilla makes sure of even more fidgety bits are handled automatically. It makes sure they updated their version number, tests that the minimum required version of perl is correct with Test::MinimumVersion::Fast, makes sure they won't have namespace issues on PAUSE with Test::PAUSE::Permissions, verifies they didn't forget a =back with Test::Pod, and notifies them of typos with Test::Spellunker. If all of that checks out, it updates the version number in their changelog, generates the MANIFEST based on the files stored in their repo, creates the dist, uploads it to PAUSE, creates a new commit in git, tags it with the current version number, and pushes everything to your repo. A new dev is most likely going to want to do all of those things from day one but very unlikely know which combination of plugins to add to emulate that with Module::Starter assuming they exist.

Honestly, nothing Minilla, Dist::Zilla, or the rest do to help devs out should chase you away because it's all on the author's side. And, btw, Minilla comes with support for ExtUtils::MakeMaker right out of the box if you think new devs should stick to what you're comfortable with. No plugins for them to find or install.