static vs non-static method overloading

[Gor Gyolchanyan]

Time and time again I've stumbled upon this crippling limitation,
which gives an ambiguity error if you define and refer to this:

struct Jolly
{
    static Jolly opCall()
    {
        // to simulate a default constructor
    }

    real opCall()
    {
        // makes it jolly and returns the jolliness factor
    }
}

If you try to "construct" a Jolly, you get an ambiguity error and if
you hack yourself an instance of it, you'll get the same ambiguity
error if you try to get the jolliness factor.
This particular case can be circumvented by replacing the non-static
opCall with something like makeJolly, but there are cases, when this
won't work.
For instance, the opDispatch, which would allow to do this:

struct Library
{
    void* handle;

    static Library opDispatch(string name)() @property
    {
        auto namez = toUTFz!(const(wchar)*)(name);
        return LoadLibraryW(namez); // of course, it would cache the
loaded library handle in an AA or something
    }

    void* opDispatch(string name)() @property
    {
        auto namez = toUTFz!(const(char)*)(name);
        return GetProcAddress(handle, namez);
    }

    unittest
    {
        alias extern(Windows) void* function(in char*) GetModuleHandleA_t;
        auto GetModuleHandleA =
cast(GetModuleHandleA_t)Library.Kernel32.GetModuleHandleA
        assert(GetModuleHandleA !is null);
        assert(GetModuleHandleA(null) == 0x40000000);
    }
}

The only way to achieve the same result now is to introduce a dummy
structure, which would be returned by the static opDispatch, which in
turn would implement the non-static opDispatch. This is bad, because
it's tedious and has run-time footprint.

Is this supposed to be like this or is it a bug? If it's a bug, what
are the plans (if any) to fix it?

-- 
Bye,
Gor Gyolchanyan.