Temporary objects as function parameters or when-is-this-shit-going-to-end?

[Jack Applegame]

If you don't want to get the great PITA, never create temporary 
objects in function parameters.
I recently spent a whole day digging through my reference counted 
containers library. But nasty bug was not there, but in the 
compiler.

Look at this: https://glot.io/snippets/eui2l8ov0r

Result:
> Bar.this(int): 7FFD3D60CD38
> fun: 7FFD3D60CD20
> Bar.~this(): 7FFD3D60CD20

Compiler creates struct on the stack and silently (without 
postblitting and destruction old object) moves it to another 
address. Is it normal? I don't think so.

But that's not the most fun.

Look at this: https://glot.io/snippets/eui2pjrwvi

Result:
> Bar.this(int): 7FFF87DD2D31
> fun: 7FFF87DD2CE0
> Bar.~this(): 7FFF87DD2CE0
> Bar.~this(): 7FFF87DD2D31

WAT??? Compiler creates struct on the stack copies it without 
postblitting and destructs both objects.

But if you create the structure before calling the function, then 
all will be well:
https://glot.io/snippets/eui2vn2bu1

All this greatly angered me because there are several issues 
related wrong struct construction and destruction in the 
bugtracker. Because of these bugs my low level libraries full of 
strange hacks.

I want to ask. How you guys are going to create a reliable RC 
library, if such fundamental bugs hang in the issue tracker for 
months and years. And instead of fixing them, you develop new 
minor bells and whistles.

See: https://issues.dlang.org/buglist.cgi?quicksearch=destructor

Since I myself can't fix such bugs (my knowledge in this area are 
extremely small), I have a question to Andrei Alexandrescu:
Can I donate to the D Foundation and that my donations would be 
aimed at fixing exactly these bugs?