Aliased types in Go only assignable if unnamed?

In the following code snippet the last three assignments produce a compilation error:

package main

type (
	Foo []float64
	Baz [2]float64
	Meh map[string]string
	Faq chan int
	Tet func()
	Hue interface{}
	Tai bool
	Foz string
	Bar float64
)

func main() {
	var ( 
		foo Foo = []float64{1, 2, 3}
		_ []float64 = foo
		
		baz Baz = [...]float64{1, 2}
		_ [2]float64 = baz
		
		meh Meh = make(map[string]string)
		_ map[string]string = meh
		
		faq Faq = make(chan int)
		_ chan int = faq
		
		tet Tet = func() { return }
		_ func() = tet
		
		hue Hue = "Hello, World"
		_ interface{} = hue
		
		tai Tai = true
		_ bool = tai // error
		
		foz Foz = "Hello, World"
		_ string = foz // error
		
		bar Bar = 1
		_ float64 = bar // error
	)
}

This means that, in this example, only bools, strings and floats are not assignable.
The reason for this can be found in the specification:

> A value x is assignable to a variable of type T ("x is assignable to
T") in any of these cases:
>
> - [...]
> - x's type V and T have identical underlying types and at least one of V or T is not a named type.
> - [...]

(Go Specification: Assignability)

and

> [...] Named types are specified by a (possibly qualified) type name; unnamed types are specified using a type literal, which composes a new type from existing types. [...]

(Go Specification: Types)

Combining this, the reason why the aliased assign does not work is because the types of the last three cases are named. Through this the rule is violated: Two named types are part of the assignment.

Now to my actual question(s):

Why should it not be allowed to assign an aliased string/bool/numeric to an actual string/bool/numeric, as opposed to types like slices and arrays?

What kinds of problems would the lack of this rule cause?

What kinds of problems would the specification of a string as a named type cause?

Thank you in advance.

The assignability rules mean you sometimes have to convert between named types to explicitly say "yes, I mean this string to be used as a Foo," even if they share the same underlying type. This is relevant to things like os.FileMode: it's a number underneath, but type checks will keep you from accidentally passing it to a function that takes an unrelated foo uint32. (Assignability rules affect function calls, too: you can pass an argument of any type that's assignable to the parameter type.)

Generally, this means if you have distinct, potentially confusable uses for an underlying type, you can assign different names to them. Like: the underlying type [][4]float32 could plausibly have RGBASlice, HSVASlice, and XYZWSlice type names assigned. You can't pass a RGBASlice to a function that expects an XYZWSlice. But all can be passed transparently to things that don't care about the meanings of the numbers, like if you have some all-purpose vector-math routines.

So, broadly, by forcing you to convert between named types, Go helps you distinguish between things that might have the same representation in memory even though they have different meanings and are supposed to be used different places.