some issues i encountered while reintroducing the padding with the changes of #10430 in mind:

if padding is applied on a per element basis precision should likely too:

However there are existing test cases that apply it to the whole slice:
{"%.5x", []byte("abcdefghijklmnopqrstuvwxyz"), 6162636465},

I think there are at least 3 options that can be implemented to format byte slices while correcting the padding:

1. format byte slices no different than other integer slices and apply all formatting on an element basis:
   But then "% x" should be "[ 1 2 3]" not "1 2 3"
   Then the line " String and slice of bytes: " in documentation for %x and %X should be only referring to strings.

Also should change the doc "' ' (space) leave a space for elided sign in numbers (% d);
put spaces between bytes printing strings or slices in hex (% x, % X)"
to not refer to byte slices. Since in an absolute reading of "For compound operands such as slices and structs, the format applies to the elements of each operand, recursively, not to the operand as a whole." "% x" would never be applied to the whole byte slice and therefore cant introduce space between elements.

If there should still be spaces between elements then specifying "% x" would have the (likely unintended) side effect of introducing spaces between elements and adding a space for each byte element in place of sign at the same time.

2. format byte slices in the old behavior like strings.

3. format byte slices in the old behavior but apply ' ' only to the slice but #, padding and precision only to each element. Seems to be the version that would be favored by the test cases added in fmt: empty byte slice prints one value with format "% 02x" #10430. Then an open question is still if 1 without padding should be "1" or "01". In the first case then the documentation " String and slice of bytes: ... two characters per byte" needs to be changed.

There are some things that need to be thought about here and there are also conflicts in the documentation. For example, it says that "% x" puts spaces between the elements, which implies the first element should not have a space before it, and I believe that is correct and desired behavior, while on the other hand it says the format applies to all elements, which presumably applies to the first.

This is not an urgent issue and resolving it may break some things, so I am deferring it until 1.6.

The documentation says:

However, when printing a byte slice with a string-like verb (%s %q %x %X),
it is treated identically to a string, as a single item.

The behavior is consistent with that sentence: The entire item is padded, while the 0 and space flags do apply elementwise, as one would expect.