I agree sorting doesn't make sense here. I though we do that ourselves, but it turned out that sorting is done by Python's PrettyPrinter that we use to get nicer formatting. Luckily for us it has got sort_dicts argument in Python 3.8 that is our minimum version starting from RF 7.0.

We use PrettyPrinter via our custom prepr utility and it's easy to change that util to use sort_dicts=False internally. I believe that's a good behavior for us in general, but I need to run all tests to know does it break something unexpected. If it does, we can make sorting dicts configurable and use it at least when trace logging arguments. Either way, the reported problem is easy to fix in RF 7.0.

Based on tests this change affects also Log and Should Be Equal keywords when using formatter=repr. At least with Log preserving the original formatting makes sense. With Should Be Equal sorting has a benefit that it's easier to see differences when comparing bigger dicts that are mostly identical but have items in different order (order doesn't matter normal dict equality). Also in that usage there are benefits in keeping the original format, so I believe it's fine if the behavior changes. If others disagree, we can consider sorting dicts in that case.

Looking at the code, the change affects also trace logging keyword return values. There the change is definitely a good idea. I believe we can change prepr behavior universally, but I can make sorting configurable anyway so that it's easy to change case-by-case later if needed.

Notice that running tests with the trace level isn't generally a good idea because it increases log file size and can reveal sensitive information. If you want a certain argument to be logged, it's typically better to explicitly log it. For example, adding

Log    ${targets}

or

Log Many    &{targets}

or

Log Dictionary    ${targets}

would get the dictionary logged. Starting from RF 7.0, due to this fix, using

Log    ${targets}    formatter=repr

would work too and would probably give nicest output.

Thank you. For now I implemented simple workaround and I'm waiting for RF 7.0 then.
I'm aware of TRACE log level disadvantages but it's only used for local script development. :)