As the docs put it:
[opaque] is typically used for type safety when interacting with C code that does not expose struct details.
In C, this is reasonably common, for a few reasons, already adequately covered.
If you want a Zig dynamic library for whatever reason, it’s going to be using the C ABI, so the opaque pointer approach is justifiable.
If someone wanted to make module code which blobs up a struct, there’s nothing stopping that. You could really drive the point in by casting the byte array with @bitcast into a big ol’ unsigned integer, if you wanted to.
I don’t think that would be a popular choice, however. Feel free to experiment, and if it catches on, maybe it’s worth adding more language support for doing that.
But you’ve already identified a situation in your own code where it does make sense: a host/guest program, where you want to be able to pass Zig assets into a hosted runtime, and have guest code reach back into Zig with that data. I could see this being useful in Wasm, or JavaScript like you’re doing now. Lua, maybe. Any situation where the nature of the data is such that it has to be handed back to the Zig host for anything useful to happen to it.
What I’m not seeing is what promoting a byte blob to a special sort of opaque type is adding to the picture. It’s been proposed already, and it didn’t catch on.
No proposal based on access control has been accepted, and it will probably stay that way. I consider that a good thing, because Zig is a low-level language, structs are literal regions of memory carrying data. It’s possible to obscure what that data means, but not what it is, so sufficiently determined user code can always figure the rest of it out, and all that private fields or sized opaque types (which is just a struct where all the fields are private) can do is make life frustrating and annoying for whomever has to make some internal use of an asset for which some of the type metadata has been excluded.
It’s not even difficult to do this ‘by hand’, it is in fact very easy. There’s no advantage in making it easier than it already is.