Sorry, but from here we will have to agree to disagree! Everything I do is for a reason.
Take this as specimen of why I let my employees decide the implementation details by themselves. Just for fun:
Not required for the software to function, but for basic functionality.
The goal of my software is making computing as easygoing as possible. If I make an application that automatically chooses which emulator to launch is for making it easy for a noob to use it.
So only installing Wine, and forcing the noob to type “winecfg” in a terminal for getting Windows’ fonts to be usable, because they being minuscule by default, is a no brainer. It defeats the goal of the software.
I don’t care about how the software is organised, I care about the service it provides. I care about the usage process, the goal, and the context.
It tells the text editor to highlight as if was Bash, so the text gets easier to read.
If something has to be changed, in only needs to be changed in one place.
Since they are tested not to conflict, and they are unlikely to do so, it really doesn’t matter. It just adds complexity.
It doesn’t matter, as the folder is deleted after build nowadays. Making the name larger does nothing.
package seems more relevant than pkgver to somebody looking into the file, so that’s why the order.
BUILD instantly builds the package, so you can test it. PUBLISH instantly uploads the changes to the AUR.
It means doing the opposite than Arch, automating any repetitive task so you have to think as little as possible about them.
It means assuming the default, till stated otherwise.