I don't think that this proposal has anything to do with the no of times the link will be shared. A link will be shared a irrespective of the fact if it is readable or not.
You won't create a seperate smart contract for every file. You save the file name hash in an existing smart contract. Hence we can update the new modified content hash which will be present in the smart contract.
It won't be a dependency but would a seperate layer to resolve file name to its content hash. So things would work even if user choose to use ipfs without this system.
Yes there might be errors (using word ipfs or IPNS) in the proposal and it's a draft so pardon me.
Multihashes and friendly names can be differentiated by a simple of condition. (Split the link, check if it has "Qm" then hash otherwise it's a file name).
Well then ethereum it is. And no not all paths, if it's a file content hash then there is no requirement to call the smart contract.
If phishing is your concern then it exists in centralised system as well. But I can read the link and understand that it is asking for logins, it it were just a hash then I wouldn't recognise it and simply provide my login to the bad guys.
Perhaps by using an advanced datastructure and not a simple dictionary we can reserve a some names.
Reserve google.com so that links such as google.com/login , cannot be used by people other than the owner of google.com domain name.