Why is BIP32 root key different for different standards(purposes)?

Question

When generating key on https://iancolemen.com/bip39/, the BIP32 Root Key changes as I change the derivation path tab, e.g. BIP32, BIP44, BIP39 etc. Why is this the case? Isn't BIP32 Root Key the m at the beginning of the derivation path and the different standards are subsequent purpose that should not affect the root key?

Contrary to the above, when I generate addresses with the following code in go, the master key printed always matches the BIP32 Root Key on iancolemen.com. And changing the purpose does not affect the address generated in the end, it is always a BIP32(legacy) address, instead of a segwit which I would expect from BIP84.

m, err := hdkeychain.NewMaster(seed, chainParams)
if err != nil {
    panic(err)
}
fmt.Println("bip32 root", m.String())

purpose, _ := m.Child(hdkeychain.HardenedKeyStart + 84)
coin, _ := purpose.Child(hdkeychain.HardenedKeyStart + 1)
account, _ := coin.Child(hdkeychain.HardenedKeyStart + 0)
receiving, _ := account.Child(0)
index, _ := receiving.Child(0)
fmt.Println("address", index.Address)

EDIT: The wrong address printed in go was a result from not properly encoding the addresses to bech32 and by default they are interpreted as legacy addresses. The keys themselves are alright.

Answer 1

If you look closely, you'll notice that BIP 32 and BIP 44 actually have the same root key and it begins with xprv. Then BIP 49 and BIP 141 also have the same root key and it begins with yprv. BIP 84 has a root key that's different from the others that begins with zprv. Now if you were to take all of those root keys and Base 58 decode them, you'll find that they actually are identical except for the first 4 bytes and the last 4 bytes.

The last 4 bytes are because of the checksum used in Base 58 Check encoding.

But why are the first 4 bytes different? They are different because BIP 49 specifies for extended keys for nested segwit addresses should begin with the prefix yprv and ypub. Even though this is specific to BIP 49, this has been more generally applied to all extended keys for nested segwit addresses, thus you see it used for BIP 141. Then BIP 84 specifies that extended keys for native segwit addresses should begin with the prefix zprv and zpub.

These prefixes are what cause the different root keys as changing the prefix will cause the entire serialization to change as well.

By this logic, the xprv and xpub prefixes used previously then indicate that legacy addresses should be made. Hence BIP 44 shows xprv.

However BIP 32 is what specified the xprv and xpub prefix, and really this prefix is supposed to be independent of the derivation paths used and the addresses to be derived. BIP 32 is solely concerned with keys, not addresses. So xprv and xpub are used for general BIP 32 key derivation stuff too, which can make this confusing. But that's also why the BIP 32 tab shows xprv.