The SDK images do not have a consistent pattern of base images. The Ubuntu and Debian images are based on the buildpack-deps:scm images which provide a rich experience as they include curl, wget, ca-certificates, git, etc.

When Windows containers came around, the option to base the SDK images on buildpack-deps:scm was unavailable. As a result, the Windows SDK images are based on the base NanoServer OS images. On Windows curl is already included but SCM (e.g. git) is not. With 3.0 PS is included which provides other options for downloading content. IIRC no feedback has been provided in regards to not having git in the image.

When Alpine support was added, the buildpack-deps:scm option was again unavailable. The buildpack-deps repo maintainers believe the Alpine images are not intended for development scenarios (docker-library/buildpack-deps#51 (comment)). As a result the Alpine images were based on the runtime-deps images. The runtime-deps were chosen over the base Alpine image because of the need for the native dependencies.

I think the correct choice was made to utilize the buildpack-deps:scm images where available. For the images where buildpack-deps is not available, I think adjustments should be made. In these scenarios basing the SDK images on the runtime images would support maximize layer re-use. This will provide customers with a better experience. This is valuable in particular with the Windows images as they are larger when compared to the Linux images. The runtime specific layers on disk are ~70 MB and the aspnet layers add another ~20 MB.