Ok, here is a draft of the document, please take a look.
In comparison to the proposal outlined here, this approach requires no new keywords or grammar productions (just adds a decl modifier, and undisables an existing grammar production in type aliases), it composes properly towards the 'future directions', and doesn't have the unsolved issues that the original proposal has w.r.t. future directions.
it also seems like a very nice thing because API authors can choose to expose exactly what they want, and because these types can be passed and returned, it may also provide a mechanism to solve the latent issue with the C importer, where we don't know how to import opaque types from C while preserving their identity.