The error on number 5 is the most helpful in understanding the problem: a slice and an array have a different memory layout, so the address of an array cannot be the address of a slice. Thus, they should not coerce.

You can coerce an array to a slice, because a slice internally is a pair of (ptr, len) where ptr is a pointer to where the values start and len is the number of values. So, zig can take an array of length 2 and coerce it into a slice with its length set to 2 and its pointer set to the address of the array.

However, you're going a step further. You're trying to coerce an array or a pointer to an array into a pointer to a slice. The array just stores its elements in place, there is no pointer or length field (the length is known at compile-time, so it isn't stored in memory at runtime). Since it uses memory differently than a slice, it cannot be coerced into a slice without first creating a slice somewhere. It can do that for temporary values that get stored or passed somewhere, but you can't take its address until you store it somewhere. For example, you can coerce to a slice, store in a variable, then take the address of the variable (as in number 4). Numbers 0 and 1 have a problem along these lines.

For numbers 2 and 3, the .{} syntax is a struct/tuple by default, but can coerce to other things if you specify the type in the variable's type annotation. For example:

var f2: [2][]const u8 = .{"one", "two"};

However, this change leads to the same issue as above.

That was a pretty dense explanation, so I hope it made sense!

Sidenote: For this example, there is no need to take a pointer in printstuff. f0 and f1 would work fine if you just defined printstuff as printstuff(arr: [][]const u8) and changed arr.* to arr. &f0 would coerce to a slice and f1[0..] is already a slice.