If the method name doesn't reflect the functionality then it's a bad name. So it should be the same. You make a distinction I don't.
You guessed the class.forName because that's a pretty easy case in general. With the ASP.NET class you just decided the class was badly designed instead (so I'm pretty sure you wouldn't have guessed which methods were static or not).
But we can go further, in .NET the Object class has two methods called Equals, but one is static and the other not, and the way of knowing it is because of the number or arguments, not because the method name. The same name, the same functionality, but in one case is instance, because it's comparing one object against the instance and the other is static because it's comparing two objects. It's a pretty good example that name has nothing to do with static/instance.
Math libraries are full of those examples too. If I tell you that the class Vector3 has a method called Normalize, is it static or instance or both? You can't answer that, as the three answers make sense and it depends on how the implementer decided to code the library.
Saying that "there are quirks and what are your credentials" is a bit short. Those examples ("clazz" and a mix od static and isntance members) are both in the first classes I looked up. I didn't have to look for such bad examples, and I don't think .NET etc. are necessarily good examples just because they're produced by big firms. And I know that big firms sometimes have to make do with compatibility they'd rather live without. Saying 'look these are good examples except when they aren't and the guys have excuses' doesn't go far.
Not only they are produced by big firms, they are produced by big firms that employ some of the best talent in the world. So saying that they aren't good examples of design and naming when they are some pretty successfull APIs, with some of the most clever people involved and with a ton of economic resources is well, debatable. And I don't know you, but I know that the people who work on those things are way clever than I am (just reading their blogs shows that they know a lot about what they are doing). You just looked two random classes and ditched the design of both APIs, even if your choosen examples (at least in .NET) were flawed and even when you don't seem to know why they did that, you simply decided it was wrong, instead of thinking there were reasons to do that (even if you don't know or understand them).
I said some LISP code, which with macros is readable. It could read like this:
(:total-water-usage ( + (the :hotel :water-usage) (the :bank :water-usage) ) )
They used a 'the' function which looked silly as it didn't seem to explain anything but made reading the code actually meaningful. (It also did some conversions to make sure units were respected.) There were also macros that made function calls read like English, something like (transfer :from-account 1 :to-account 2 :amount 32).
English words were there to provide meaning while parenthesis were a necessary evil. You could explain to a non programmer what the method did quite easily, because they had used some conventions that made it as clear as possible despite the parenthesis clutter. The this you're advocating is just adding the same kind of clutter as those parenthesis in my opinion.
At least for me, the following VB:
Function CalculateWaterUsage(ByRef hotelWaterUsage As Integer, ByRef bankWaterUsage As Integer) As Integer
Return hotelWaterUsage + bankWaterUsage
Looks pretty english readable... And parenthesis are like semicolons, something you have to put to make code legal. Putting or not this. is made with an intent, you may agree to it or not, but it's totally different.
Edit: I'm not saying the .NET API is perfect, it has rough edges, but that's expected/understandable on such a huge amount of code. But overall, the design is pretty good even if it has some mistakes here and there.