If there is any documentation of this behavior, it will probably be in the area of compiler production of temporary variables to hold intermediate results when passing function results as parameters. Consider this code:
procedure UseInterface(foo: IInterface);
begin
end;
procedure Test()
begin
UseInterface(Create());
end;
The compiler has to create an implicit temp variable to hold the result of Create as it is passed into UseInterface, to make sure that the interface has a lifetime >= the lifetime of the UseInterface call. That implicit temp variable will be disposed at the end of the procedure that owns it, in this case at the end of the Test() procedure.
It’s possible that your pointer assignment case may fall into the same bucket as passing intermediate interface values as function parameters, since the compiler can’t “see” where the value is going.
I recall there have been a few bugs in this area over the years. Long ago (D3? D4?), the compiler didn’t reference count the intermediate value at all. It worked most of the time, but got into trouble in parameter alias situations. Once that was addressed there was a follow up regarding const params, I believe. There was always a desire to move disposal of the intermediate value interface up to as soon as possible after the statement in which it was needed, but I don’t think that ever got implemented in the Win32 optimizer because the compiler just wasn’t set up for handling disposal at statement or block granularity.