Short answer: it is not true for libraries or tools "in general". Each vendor can guarantee for his library or tool whatever he wants. There are libraries and tools where the vendor does guarantee
- functional equivalence and the equivalence of certain aspects of non-functional requirements
- just functional equivalence, not more
- only syntactical equivalence
- none of the above
And even if a vendor guarantees you something for a specific version or version line of a product, noone can hinder him legally to create a new version or product line with a different API, or different non-functional behaviour. So the question "can it be changed" is not really the correct one, instead you should ask is "how likely is that for a specific tool or library?"
For your example of the
StringBuilder class, IMHO it is absurdly unlikely that MS will change its run time behaviour within the .NET framework in a manner so the effort of writing such a class by yourself will ever be worth it. The cite of your friend sounds more like
superstitious nonsense an overcautious misconception for me, at least for this case.
Microsoft added such a class explicitly to the .NET framework to provide a mutable alternative to the immutable
String class with certain performance aspects in mind, the documentation of that class is very detailed about that. MS in the past tried to keep newer versions of the .NET framework mostly backwards compatible to older versions, even if that means not to fix certain bugs or live with some imperfectness. And changing the run time behaviour of a
StringBuilder in a significant manner would not break only your program, but most probably ten thousands of other programs -
StringBuilder is one of the central core classes of the framework, and widely used among the .NET ecosystem. That is nothing any sensible library vendor would change lightheartly. When they annoy their customers too much, customers start looking for a different vendor, and that will cost them money.
The same is true for lots of other tool or library vendors, and those which do not care for this risk to annoy their customers until they look for a different vendor.
To give you another example: the C++ standard library gives explicit specifications for the run time behaviour of std::sort, it guaranteed to be
O(n * log(n)) for the average case, see Wikipedia.
And for question of "grep": I am pretty sure there already exist different implementations of
grep from different older unix or unix-like systems, and I would be astonished if they all have the same run time behaviour. The Posix standard makes them have same command line switches, at least for any Posix-conform OS. However, today the fact Linux including GNU grep is so popular, you can probably rely even on its non-functional behaviour at least on any decent Linux system.