I can give two real-world examples. Example one shows the issue with having similar but divergent services attempt to share namespaces. The second shows the issue of accidental overlap that impedes the advancement of services on the IC.
Example one: Origyn has been trying to get the OGY token listed on a DEX for the last 3 months. They have a pipeline of loaded buyers and sellers that want to participate in trading on the DEX and further distributing the token. The OGY token was built on the ICP ledger tech. At the time they deployed the ledger, the public API did not have a .transfer function. Thus, when Sonic launched their dex and they said that OGY needed to have the DIP20 standard implemented Origin looked at adding that to the ICP Ledger. Thankfully there was no collision and so Origyn went about attempting this. External geopolitical issues slowed the progress, but finally, they were ready to roll it out and when they merged the latest ICP ledger they discovered that .transfer had been added to the public API. The .transfer in the DIP20 standard takes (principal, amount) and the ledger takes (TransferArgs). They now cannot have both in the OGY ledger. Thousands of dollars of work has been wasted, and significant (millions of dollars)value and interest remain on the sideline until the issue is resolved.
The current next best solution is for Origyn to create another canister that implements DIP20 that has “God” status in our ledger. This second canister can move tokens from one account to any other account. It also keeps track of allowances and enables a transferFrom workflow(which is a terrible and exploitable flow but what DIP20 and sonic require). This solution also slows the user experience because we now have to wait for 3 rounds of consensus to do a transferFrom. This solution also has second-order consequences because the Origyn NFT project handles payments and was distinguishing between tokens by using canister ID as part of our primary key. Now the OGY token will have two canisters that are both legitimate methods of transferring tokens. More work gets more complicated simply because we can’t just add the dip20 end points to the main ledger and keep track of allowances in that ledger.
Example two: The Origyn NFT project is attempting to combine a number of different features into an NFT canister. One feature is to transfer NFTs from one owner to another. The EXT-NFT function has a .transfer function that moves an NFT from one owner to another. The Origyn NFT may also hold a collection-based fungible token for governance as well. If it implements the DIP20 standard or the ledger standard the .transfer function will be impossible to implement because the NFT .transfer function is in the way. We could host the token on another canister but this breaks all kind of interoperability goals that Origyn has. Origyn wants a super standard that has NFT functions in it and Token functions in it. This super standard should be interoperable with all kinds of tools(NFT marketplaces) that only care about the NFT part and all kinds of tools(wallets, dexs) that only care about the fungible token governance part and we want one canister to handle both of those. With .transfer_ext_nft; .trasfer_ext_fungible; .transfer_dip20, .transfer_ledger we can support multiple marketplaces, wallets, and dexes even if they only support one of the ledger functions. With .transfer .transfer .transfer and .transfer Origyn will have to pick and choose and make our lives more complicated.