From reviewing the code some reflections:

• The fields from the record being spread are not type checked again, but their type is simply used as-is. (That might explain why the seemingly needed code to add option to the type has no effect).
• Another possibility is to extract the untyped parse tree for those fields and type check again. Though doing that would preclude the possibility of, in future, know what parts are coming from a spread and what parts are not. It might be useful, or it might not, to be seen.

Now that all the new features exist in isolation, there are a bunch of questions to answer:

• Are there unboxed records (perhaps with exactly 1 field if I remember)
• If they exist, can one spread it?
• Does it become boxed if it's not declared unboxed?
• If it's boxed, can one make one unboxed out of it?

So it looks like the design is not finished here. We can try to answer some of these questions and iterate some more see what comes out of it.

The question about unboxed apply to type coercion too.
Are we simply allow to coerce a boxed to an unboxed record and the other way round silently? That would not be safe.
What about @as(...)? Are we taking that into account correctly? Both in terms of spread and of type coercions.

Most of these questions can be answered by writing a few little tests.

Link to original conversation: #6154 (comment)

So, questions are (and my personal thoughts next to them):

• Are there unboxed records? Yes I believe there are, allowing just one field
• If they exist, can one spread it? I don't think we should allow spreading them, seems like a niche use case that isn't worth complicating things for
• Does it become boxed if it's not declared unboxed? Can skip if we disallow spreading them
• If it's boxed, can one make one unboxed out of it? Can skip if we disallow spreading them
• Are we simply allow to coerce a boxed to an unboxed record and the other way round silently? That would not be safe. What about @as(...)? Are we taking that into account correctly? Both in terms of spread and of type coercions. Maybe we shouldn't allow type coercion on unboxed records either. And for @as, I assume we'd have to account for them in coercion as well, as in @as must exactly match between types for them to be considered equivalent.

My thoughts, cc @cristianoc