Confusing .fmt behavior with nested Lists

Question

The docs say that fmt

Returns a string where each element in the list has been formatted according to $format [the first argument] and where each element is separated by $separator [the second argument].

Based on that description, I expected to be able to call .fmt on a List of Lists, and then pass a printf-style format string containing a % directive for each element in the inner list. But that doesn't work.

If you'd told me that I was wrong about ^^^^, I'd have expected that .fmt was auto-flattening its arguments and thus that each argument would be formatted and separated by the $separator. But that's also not what happens.

Instead, running this code

say (<a b c>, <1 2 3>, <X Y Z>).fmt('→%03s|', "\n=================\n");

produces this output:

→00a| →00b| →00c|
=================
→001| →002| →003|
=================
→00X| →00Y| →00Z|

That is, the format string is applied to each element in the inner lists, those lists are then stringified (without using the format string; note the between each | and → character), and then the separator is inserted between each outer list.

That leaves me with three questions:

1. Have I correctly described/understood the current behavior? [edit: nope. See below]
2. Is this behavior intentional or an odd bug? (I checked Roast, but didn't see anything either way)
3. Assuming this is intentional, why? Is there some way that this is consistent with Raku's general approach to handling lists that I'm missing? Or some other reason for this (imo) surprising behavior?

Edit:

After further investigation, I've realized that the behavior I observed above only occurs if the format string contains a width directive. Changing the →%03s| format string from above to →%s| produces the following output:

→a b c|
=================
→1 2 3|
=================
→X Y Z|

That is, without a width, the format string is applied after the list is stringified rather than before.

So I'm back to being confused/thinking at least some of this behavior must be buggy.

Answer 1

Ok, it looks like there were at least two bugs here. This should be fixed with https://github.com/rakudo/rakudo/commit/a86ec91e36 . Writing spectests for these situations, would be appreciated :-)