Update Overview.md with feedback from 1/23/2024 meeting

[tlively]

• Change waitqueue to have a shared eqref control word
• Note that unwakeable threads can be garbage collected
• Change the JS API to reuse the existing constructors
• Add ref.shared.eq

[conrad-watt]

@rossberg is having a separate instruction for eq on shared references the right approach? We had some vague "principal types" reasoning for it in the meeting.

[conrad-watt]

I'm actually having some second thoughts about my proposed change to waitqueue. I'm starting to feel like you would rather have a parameterised waitqueue T type where T is some subtype of eq rather than just waitqueue with an eqref inside. In particular with the waitqueue I floated, the CAS-loop strategy for implementing i31 atomic arithmetic requires a downcast with each loop iteration. Being able to define waitqueue i31 would avoid this.

So the conservative thing might be to stick with waitqueue i32 for now, since I think one might want a parameterised type for waitqueue with a reference inside.

[rossberg]

Shouldn't struct/array.atomic.set be valid for i8 and i16 as well?