go1.4, go1.6, tip
( note that with the recent changes i made to fmt i was careful to not change the behavior but leave the issue open)

https://play.golang.org/p/TrmwckEwqu

          %T | reflect Type | %#V
       uint8 |        uint8 | 0x0
       uint8 |        uint8 | 0x0
     []uint8 |      []uint8 | []byte{}
     []uint8 |      []uint8 | []byte{}
      main.S |       main.S | main.S{in:[]uint8{}}
      main.S |       main.S | main.S{in:[]uint8{}}
    [3]uint8 |     [3]uint8 | [3]uint8{0x0, 0x0, 0x0}
    [3]uint8 |     [3]uint8 | [3]uint8{0x0, 0x0, 0x0}

i would expect uint8 to be consistent everywhere in agreement with %T and especially for []uint8.

i would argue it should and could be changed to always print uint8 because:

• there are no issues that reflect package treats byte as uint8 in type strings (its only an alias anyway)
• there is no way i know of to differentiate byte from uint8 with the reflect package or at all during runtime so a fix to differentiate the cases seems impossible
• most cases already print uint8 types even if its specified as []byte inside e.g. a struct
• %T and %#v are inconsistent for the type specification currently
• there will be no extra code needed for %v,%d,%b bytes formatting vs normal array,slice formatting so it also automatically agrees e.g. what to print for nil slices.
• if the behavior is changed to print []byte as []uint8 no test in std lib besides fmt_test breaks (those were mostly only added after go1.6)
• there is precedent for fixes after go1 that made %T and %v consistent and not print byte type fmt: Printf %#v loses array type information for [...]byte-derived types #4685 but uint8 is still shown as byte
• the language spec defines "byte alias for uint8" not uint8 as alias for byte