Minor: "prolog flag option lists" do not follow option list semantics

[dtonhofer]

Suppose we have:

?- 
set_prolog_flag(answer_write_options,[quoted(true),portray(true),max_depth(10),attributes(portray)]).
true.

Then a longish list gets elided at depth 10:

?- 
length(L,200).
L = [_15876,_15882,_15888,_15894,_15900,_15906,_15912,_15918,_15924|...].

Then we prepend max_depth(100) top the options list.

?- 
current_prolog_flag(answer_write_options,Options),
NewOptions=[max_depth(100)|Options],
set_prolog_flag(answer_write_options,NewOptions).

The new option actually gets prepended instead of the option list getting collapsed into a new one.

This might or might not be what is expected; there is as yet no collapse/2 predicate in library(option) either, actually, though there should be IMHO ("collapse" behaviour would be unavoidable by construction if options lists really were option dicts, which, as I understand, they can be).

So we now have two entries for max_depth/1:

?- current_prolog_flag(answer_write_options,Options).
Options = [max_depth(100),quoted(true),portray(true),max_depth(10),attributes(portray)].

Okay, one can live with that.

But the option list semantics would command that "first option with a given functor wins", so I am expecting "max_depth(100)". However, this is not so:

?- length(L,200).
L = [_16122,_16128,_16134,_16140,_16146,_16152,_16158,_16164,_16170|...].

That's unexpected.