If you try and install two packages that have the same binary, the second installation will fail with an error telling you that you need to set the meta.priority of one of the packages. This is definitely true for nix-env -iA. I haven’t tested this scenario with systemPackages but I have to assume a similar error shows up there.
If you define meta.priority on one of the packages to something non-default, then both packages can be installed at the same time, but the one with the higher priority (defined—counterintuitively—as a lower meta.priority value) is the one that ends up in your PATH. IIRC if the lower-priority package has files not present in the higher-priority package those files will still end up linked into your profile; which is to say, it resolves conflicts on a file-by-file basis rather than omitting the whole package.
If you don’t want to override a package to change its meta.priority you can also use e.g. nix-env --set-flag priority 5 foo21 to set the priority of foo21 to 5, but the problem with this approach is you can only use it on already-installed packages, so you have to install the one you want to have as lower priority, then set its priority, then install the one you want to have as higher priority.
All of this is assuming that the two packages actually have distinct names. If both packages have the same name but merely differ in version (as I assume python3.6 and python3.7 are) then the second installation will actually replace the first. You can use the --preserve-installed flag to nix-env to instruct it to not uninstall the old package first. This behavior is specific to nix-env; specifying both packages in systemPackages will try to install them both.
The hash is derived from the instantiated derivation. As for the downloaded sources, that actually ends up as a separate derivation with its own hash (which the package derivation then includes and therefore affects the package derivation’s hash). most sources are specified as fixed-output derivations, meaning the package definition says what the hash is (and then Nix checks it when it actually downloads the source), so the output hash can be calculated without downloading anything. For a non-fixed-output derivation, Nix has to actually fetch the source before it can calculate the output hash.
I don’t know about anyone else, but I use “package” to refer to the whole package definition that declares the software, whereas “derivation” is actually a specific technical term, where a package is usually comprised of at least 2 derivations (the package derivation and the nested derivation for the package sources). Informally you can use them interchangeably but I usually opt for “package” in the informal context.