Just my opinion on it, quite unlikely for Gradle, totally off-topic here for Maven, and the build tool should not be aware of the VCS - if any - or it would need to be aware of all VCS and check for each and every of them, that’s just out-of-scope. The build tool also does not check that all fiels are checked in with the correct encoding or similar. Having the executable bit missing in VCS or having forgotton to add a proper .gitattributes that makes sure the line-ending is proper and so on is just a bug in the project like any other bug, that at some point in time is found by someone and then fixed by someone. And in this case it is a rather easy find and fix and thus should not waste time on every Gradle execution just for the rare case that this bug is there. If you want that for your builds, implement it as plugin and apply that everywhere.
Recommend avoiding wrappers, since they tend to cause more integration problems than they solve.
No they do not.
Don’t get me wrong, this might be true for all cases you have seen and counted.
But for me it is the exact opposite, and especially with Gradle which is in active development and regularly has breaking changes it is essential to have the wrappers.
I don’t think wrappers will be discouraged and if they will be, I’ll voice against this as they make very much sense and should be available in each and every build.
I consider any build that does not have the 4 wrapper files as having a build bug.
In wrapper documentation, note both the chmod (UNIX) and the git (any OS) commands for resolving execution errors.
Imho that is largely out-of-scope of the Gradle documentation.
Also those using the commandline should usually also be aware how to use chmod.
If you would start with this, you would also have to document for all other existing VCS how to handle it.
It is not even documented how to run Gradle in which shell.
For example on bash and similar you have to use ./gradlew,
on cmd you have to use gradlew,
on ps you have to use ./gradlew or .\gradlew.
Well, except if in the bash and similar case you have . in your path, then you can do gradlew.
Or if you are on an older version of ps, then you must use .\gradlew.
And if you use ps you also have to be super careful because of the (imho) non-sense own argument parsing and manipulation it does.
…
See where that leads to?
You would in the end more or less to document various other tools and for mutliple versions, …
This is just out of scope of Gradle and its documentation.
But having said all that, this is a community forum and I am just a user like you.
If you want to suggest this as feature request, you need to open a feature request ticket. 