Log line 22107 ("Requested split points lookup") logs dehydrated minKey and maxKey attributes as structured data, which for compound shard keys could present the same parsing difficulties for duplicate key names discussed in
An operationally related log line, 21908 ("autpsplitted chunk") does have a readable, hydrated chunk range, but it's within a single semi-structured chunk string that includes shard, lastmod, and a hydrated chunk key range (this seems to be from chunk.toString().
I think that ideally we would have the best of both worlds in each of these lines, structured data AND a hydrated key range.
To provide a specific request as a strawperson:
1) In 22107, hydrate minKey and maxKey values
2) In 21908, replace the chunk attribute with separate lastmod and hydrated minKey, and maxKey attributes (omitting shard given that autosplitting is now local to the node)