We don't need more options. Use the tools already available to you.

I understand your need to minimize makepkg, I really do. Still, I think there's a place for macros, if at least as third-party supplements. makepkg itself is a package creation macro. Technicially it is possible to do everything makepkg does in a terminal, but we have this macro to save time, confusion, and trouble. I only intend to save time, confusion and trouble. I came up with qqbuild quite a while ago to resolve the difficulties I had with doing it the ways you suggest and to minmize editing makepkg.conf (which I personaly consider risky as well as tedious). Anyway, the point is moot if you accept the patch I proposed in the other thread.

And it is still available - libmakepkg allows anybody to distribute additions like those to makepkg. These sort of optimizations need to be provided at a distribution (or repo) level, not in makepkg itself.

Currently no such packages exist, but if you'll accept the new patch, I have one tested and ready.

Create two makepkg.conf files. One with CFLAGS for PGO pass 1 and one with CLFAGS for PGO pass 2. Use the --config switch to point at the one needed for that build. That could even be done in a tiny wrapper.

As I said, I came up with qqbuild quite a while ago to deal with a number of difficulties doing these things in makepkg. Using two config files leaves open a lot of chances to make a mistake, and users would then have to edit both files any time they needed to make a change to one. There are a few reasons why my pgo macro figures out for itself if it should be generating or utilizing. Another reason to have a pgo macro in (lib)makepkg is the creation of PROFDEST. At its best, qqbuild could only handle pgo when used in the build directory, and as I mentioned in the forum it did silly things like make the profile directory before build() ever ran--thiese are limitations of /wrapping/ makepkg. Also, it isn't important for makepkg itself, but this solves a problem with AUR helpers, like yaourt, that don't keep build directories around after packages install. Again, moot point. The new patch I've proposed will allow for users to create and distribute additional BUILDENV options through libmakepkg for whatever their needs may be as supplemental packages, and they won't be coming to you if they have trouble with them.