In the current implementation of TStringlist, there is a property SortStyle, which is somewhat similar to the property Sorted. However, it is different from sorted in that it allows 3 values: sslnone, which corresponds to sorted=false, sslAuto, which corresponds to sorted=true, and sslUser, which correspnds to ????
This third value introduces some inconsistency. If the user is responsible for sorting, as is written in the documentation, this must be meant to be done by caling customsort - otherwise it would make absolutey no sense to leave sorting to the user. And in addition the procedures used for comparing auto-sorted procedures are local to the Stringlist unit, so the application programmer would not even be able to use these methods for sorting himself.
The code for find looks currently ike this:
function TStringList.Find(const S: string; out Index: Integer): Boolean;
var
L, R, I: Integer;
CompareRes: PtrInt;
begin
Result := false;
Index:=-1;
if Not Sorted then
Raise EListError.Create(SErrFindNeedsSortedList);
// Use binary search.
...While adding items to such stringlists works like for TStrings (making the stringlist unsorted instead of "sslUser" sorttype) it is currently possible to use the find method on such a stringlist directly without error message (And IndexOf uses binary search which won't work correctly). Both methods should treat such stringlists as unsorted (-> find not allowed, IndexOf works sequentially), as the compare functions used in the binary search normally will be incompatible with the sort order of the stringlist.
I wonder if there is any useful purpose for the value sslUser. Anyway, the stringlist code itself should always treat such stringlists like unsorted, i.e. should never use "if sorted", but always "if SortStyle=sslAuto".