This is not quite right. While the wrapper task does use some “generator” classes, the exact gradle-wrapper.jar file is included in the Gradle distribution. The wrapper task copies the bytes from the classpath to the destination in the current project. The hash should always be identical and Gradle even provides a GitHub action to validate that the hash matches a released version so that someone can’t sneak a malicious version of gradle-wrapper.jar into a PR.
This would be expected on first run. The wrapper task is initially designed to install the wrapper for your current Gradle version, which if you’re starting from scratch, would be the version installed on your system.
When you perform an upgrade from an existing project using ./gradlew, things occur a bit differently. You still run the wrapper task, but the task executes with your current version (Gradle 6.0.1). The arguments only change the values that are written to gradle-wrapper.properties. The gradle-wrapper.jar file is still the one copied from the 6.0.1 distribution. The next build run using gradlew will download the new version distribution and use the new version (Gradle 6.3).
Therefore, if you’re doing an upgrade using ./gradlew, and want the wrapper files to be completely up-to-date, you’ll want to run the wrapper task with the version/type arguments twice in a row. The first run will update gradle-wrapper.properties. The second run will update the remaining files. Generally speaking though, it’s perfectly fine to run new versions of Gradle with ancient wrapper files unless you specifically have a problem with something that was addressed in the wrapper updates.