it took some digging but I found a couple of pieces of information
1) according to the documentation auto overloading works only on the same unit.
There is only one case where the overload modifier is mandatory: if a function must be overloaded that resides in another unit. Both functions must be declared with the overload modifier: the overload modifier tells the compiler that it should continue looking for overloaded versions in other units.
2) It does not work on ancestor classes even in the same unit, you have to be explicit in order to avoid surfacing methods that might be problematic.
If the overload keyword is not present, then all overloaded versions must reside in the same unit, and if it concerns methods part of a class, they must be in the same class, i.e. the compiler will not look for overloaded methods in parent classes if the overload keyword was not specified.
Which makes sense in a way It just doesn't make sense in this specific case (my opinion).
That clears things up nicely.
Yes, you are right, I should've said:
"TFileStream has two constructors that are not marked as overload, meaning you can not have an instance of TFileStream except through its constructors."
Erm you mean that it explicitly hides the ancestral constructors. The way you said it you can replace tfilestream with any class and you will be right

.
none of them marked as overload;
That is my point.
Your point of what?
All constructors are equivalent. The only difference is that on thandlestream I pass the handle returned from a os native fileopen call instead of the file name and on the second one I pass the file name to open for me.
thandlestream's constructor does not know about FFileName and will not change its value. That's what I meant when I said "not mutually equivalent."
True then again even if it knew and change it what exactly is the value of that property? Where it is used exactly? What problems might arise if it is empty?
I can't instantiate a thandlestream because the file access code is on the tfilestream and I can't use the ancestral constructor to pass my handle. See the problem?
I thought you chose these two classes as an example to show a constructor problem.
Not really I chose this specific example to ask about an inconsistency that puzzled me, mainly because it is extremely useful to be able to call any of the 3 constructors (its the developers responsibility of course to make sure it works as expected in all cases) expanding the class functionality. If it ended up to be a bug then I would have filed a bug report, now that it seems to be by design if people find it useful then I might file a feature request. In any case I'm going to duplicate the code in my own library, I do not think that I will be able to call the inherited method even if I created a class inherited from tfilestream.
OW well more work for me yeah!