Unkeyed literals are definitely useful. But the counterargument is that by making keyless field order part of the type, you're creating an implicit protocol, one that can easily be broken, and so it comes with downsides.

The odd thing is that Go permits fields to be omitted for the keyed literals, but not for the unkeyed ones. So keyed literals are less strict, as you point out, from the point of view that a caller should know what they're initializing, which is not possible when the evolution of a program mandates that new mandatory fields be added to a struct. I've been bitten by this so many times.†

One solution to your desired functionality would to let types declare a constructor that can accept ordered arguments. Then the key order could be part of that signature, and you could support it for all time. I can imagine a bunch of possible syntaxes that could work here.

___

† As an aside, Rust is super strict here: A struct literal must have keys, and all keys are mandatory, although its literal syntax supports splatting, so you can merge in a default empty version:

  let foo = Foo { something: 42, ..emptyFoo }

That gives you the best of both worlds, in my opinion.