Automatic provides and replaces are a no - e.g. kernel26-foo packages do not conflict with or replace kernel26.

The only "gain" I can see from this is that it is easy to group packages in the AUR. But packages are already listed by name and thus grouped. And we loose the ability to just take the value of pkgname and find out what is being built. This gets a -1 from me.

Does the "split packages" feature not cover most of this? Perhaps it's a bit hack-ish, but using the packaging functions the package could be built with different options, etc.

- packages are already listed by name and thus grouped

There is more behind this idea than just grouping packages. I think the AUR mess is a real problem, and keeping the packagement the way it is is not going to help. And it's your brain that does the sorting, not the algorithm.

Also when a user submits a package to AUR, and I want to suggest a change or an updated version
- I try to contact the maintainer maybe he will accept my contribution
- If not, my only option is to create another entry
The difference here is that you upload your variant under the original package. The original is unchanged, and you don't need permissions to do it. Everyone benefits.

- we loose the ability to just take the value of pkgname and find out what is being built.
If I understand you're saying that backwards compatibility is lost, which is right.
But it can still be obtained by writing something like
basepkgname="kernel26"
variant_name="zen"
variant_scm="git"
pkgname=$basepkgname${variant_name:+-${variant_name}}${variant_scm:+-${variant_scm}}

- I'm not sure what split packages are, I suppose it's something like the kdemod build system
The problem is that if you group everything in the same PKGBUILD, which has a single maintainer in AUR,
the other users don't have the right to edit.
I like my idea because it makes contribution easier.

Setting up something with the variables you added can already be done in makepkg. Although it is recommended that you use underscores on custom variable names. I.e. using your suggestion

_basepkgname="kernel26"
_variant_name="zen"
_variant_scm="git"
pkgname=$_basepkgname${_variant_name:+-${_variant_name}}${_variant_scm:+-${_variant_scm}}

should just work. So this is not something that needs supported in makepkg. Maybe the AUR could have some knowledge of a set of custom variables. But that would need a feature request to the AUR project.

You're right, makepkg doesn't need particular support. This request should go to the AUR project.

However omitting underscores was intentional, in order to make the feature somewhat standard.
If the feature exists but is not visible, it is possible that nobody would want to use it.
Moreover, should custom variables be used for something else that there were designed ? (reserved to the user)

Yeah, I don't see why we couldn't create "variants" in the AUR interface, and give TUs the ability to "merge" packages together into one variant, and give users the ability to click "[Upload a variant of this package]"

This way there's no real need to muck up a PKGBUILD with this meta-info that's not needed by the underlying system (neither pacman nor makepkg should care about this info).

I have decided that this definelty is not going to happen in makepkg. Make a feature request for better grouping in the AUR if you like.