I forgot adding a final:

fmt.Printf("> %s\n", out[0])

prints:

pipo

:)

Strange. I can reproduce with 1.14 on darwin/amd64.
I cannot reproduce on tip, though. I guess a bisect might illuminate something.
I'll keep looking.

Looks like a hash function mismatch.
It was accidentally fixed at tip by https://go-review.googlesource.com/c/go/+/219338 . But not really fixed, just fixed for int32 and int64 keys.
The named and unnamed maps have different hash functions. When assigning one to the other, we just copy the map, the type (which contains the hash function) doesn't come along for the ride.
Still thinking about how to fix.

Here's a somewhat simpler reproducer, including at tip.

package main

import "reflect"

// complicated enough to require a compile-generated hash function
type K struct {
     a, b int32 // these get merged by the compiler into a single field, something typehash doesn't do
     c float64  // make the key not plain memory
}

func main() {
     k := K{a:1,b:2,c:3}

     // Make a reflect map.
     m := reflect.MakeMap(reflect.MapOf(reflect.TypeOf(K{}), reflect.TypeOf(true)))
     m.SetMapIndex(reflect.ValueOf(k), reflect.ValueOf(true))

     // The binary must not contain the type map[K]bool anywhere, or reflect.MapOf
     // will use that type instead of making a new one. So use an equivalent named type.
     type M map[K]bool
     var x M
     reflect.ValueOf(&x).Elem().Set(m)
     println(x[k])
}

This should print true, but prints false for 1.14 and tip.

Change https://golang.org/cl/222357 mentions this issue: runtime: make typehash match compiler generated hashes exactly

@gopherbot please open a backport issue for 1.14.

Backport issue(s) opened: #37721 (for 1.14).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.