I once did something along that line, but eventually decided on a different architecture so I abandoned that work. You can find a basic implementation of something close to what you want at Versioned modules.

UPDATE
Oops, I misread the question. Your problem is not what you think it is. It is an order of action issue. Here is the order of actions with the section commented out:

1. Start your script.
2. Go off and load the module.
3. import from the module.
4. Compile the rest of the script, including overwriting the function.
5. Execute the script, calling the function. (Get the local version.)

Here is the order of actions after uncommenting:

1. Start your script.
2. Go off and load the module.
3. import from the module.
4. Compile the rest of the script, including overwriting the function.
5. Manually import the function again, overwriting the local function.
6. Execute the script, calling the function. (Get the module version.)

As you see the issue isn't how you get the module to overwrite the local version, it is how you get the local version to not overwrite the module!

The answer is that you can't. But if you move the use to the *end* of the script you will get the module version. If you manually call import in your script you will likewise be able to get the module version. However you cannot prevent the code using the module from being able to overwrite what you exported. Which is really how it should be. Module authors should not be deliberately equipped with weapons to allow their bad assumptions to accidentally cause hard-to-fix grief for users of their code.