I had this exact question so I found this post two years later. However, I think it is important to note that this will only not compile and give the “The call is ambiguous” error if the code calling the duplicate extension methods is not in the same namespace as one of them.
If the OP were to change the namespace of his class Blah to either test1 or test2, then the code compiles, and the extension in the same namespace as the caller is used – even when both namespaces are represented in the usings. So if Blah is in the test1 namespace, “1” is returned, and if Blah is in the test2 namespace, “2” is returned.
I think this is important to add to the above answers, because I think one mainstream use-case is to have extensions in a local class library that references external extension libraries (e.g. devs share a common utility library, but have some local custom extensions that might unwittingly have the same name). By maintaining the custom local extensions in the same namespace as the code that uses them, you can maintain the extension call syntax and not have to revert to treating them as static method calls.