In the proposal draft I was working on, I used : type (similar to TypeScript) for a restricted subset of types, with the possibility of using something like TS generics for specific subtyping (i.e., kind: i32<Kind>, where the <Kind> would be erased by TS on emit). Another approach was a prefix (type) similar to what I was thinking for operator overloading:

struct Point {
  (i32) x;
  (i32) y;
  static (Point + i32) (a, b) { return new Point(a.x + b, a.y + b); }
  ...
}

But this could also theoretically be handled by decorators under the current proposal:

struct class Point {
  @WebAssembly.Type("i32") x;
  @WebAssembly.Type("i32") y;
}
// or
const { i32 } = WebAssembly.Types;
struct class Point {
  @i32 x;
  @i32 y;
}

The @type decorator approach wouldn't be the first time we've seen a similar proposal. I think littledan considered something for user-defined numeric literal suffixes as well (i.e., 123@px).

Also, it wouldn't necessarily need to be tied to WebAssembly if we went with that approach. There are a few use cases it doesn't solve though (like fixed size arrays, etc.) that I was considering here: https://github.com/rbuckton/proposal-struct#field-types

Specific cases being something like:

1. i32[8] for a fixed-size array of 8 32-bit signed integers (derived from standard C/C++ array field declarators and C# array field declarators)
2. i32[length] for a dependent-sized array whose size is derived from another field on the object (roughly based on https://docs.microsoft.com/en-us/windows/win32/midl/midl-arrays, though possibly not feasible if length is mutable).
3. i32[] for a flexible-sized array (based on C99 flexible array members https://en.wikipedia.org/wiki/Flexible_array_member)

Decorators do provide some flexibility, and we could leverage MetaProperty, i.e.:

struct class Foo {
  @struct.type(struct.i32)
  x;
  @struct.type(struct.i32, { size: 8 })
  y;
  @struct.type(struct.i32, { size: "flexible" })
  z;
}

You would run into the same issue decorators has with circular references though:

struct class A {
  @struct.type(struct.i32)
  size;
  @struct.type(B, { size: "flexible" })
  bArray;
}
struct class B {
  @struct.type(struct.i32)
  size;
  @struct.type(A, { size: "flexible" })
  aArray;
}

That was one of the other motivators for ref:

struct class A {
  @struct.type(struct.i32)
  size;
  @struct.type(ref B, { size: "flexible" }) // reference `B`
  bArray;
}
struct class B {
  @struct.type(struct.i32)
  size;
  @struct.type(A, { size: "flexible" })
  aArray;
}

Maybe a global Interop object (since anything non-Proxy related can't go on Reflect). Then you could write:

const { type, i32 } = Interop;
struct class Foo {
  @type(i32) x;
  @type(i32) y;
}

But there's plenty to bikeshed there.