using .init reliably

[Alex]

Sorry for dig out this posting, but this one is more recent, than

http://forum.dlang.org/thread/k15of5$22ub$1@digitalmars.com?page=1

and my question is just beyond the two:

I'm with you, regarding that the standard init property should 
not be overridden. But how about to override it with a custom 
init function, which has a different interface?

An example:

/// --- code --- ///
void main()
{
	int first = 5;
	//auto s0 = S.init; // this line (4) yields an error:
         // function app.S.init (int fParam) is not callable using 
argument types ()
	S.init(first);
	int second = 2;
	auto s = S(second);
	assert(s.first == first);
	assert(s.second == second);
}

struct S
{
	static int first;
	int second;

	// I'm aware of the fact, that nobody should redefine init() 
like:
	// static auto init() { writeln("oh-oh..."); }

	static void init(int fParam) { first = fParam; }

	this(int sParam) { second = sParam; }
}
/// --- code --- ///

My question has some components:

1. If this also should be disallowed: why, as it could be 
possible, that I'm not aware of existence of any init property of 
every struct.

2. Regardless of the result of the first question, line 4 of the 
example yields an error, although I didn't touch the standard 
init property. Why?

3. A practical aspect: What I try to solve is a two-stage 
initialization of an object. I know, this should be avoided. In 
order to do this, I try to separate the initializations of the 
type and its objects.
(By the way, is this the right way to go?)

Of course, I could use an external function, say
prepareType(S)(int fParam)
to do so, and this is the place, where I remembered the old 
posting and found the current one.

As we are already beyond 2.075, are there known tickets about the 
disabling of the ability to override the init property, where I 
can post the bug of the second question, in case it is one?

4. The chipped in question in the previous paragraph :)