There have been multiple instances recently of DOM code that has a callback object (Rc<...>) and needs to queue a task to invoke it. Our task queue is built on channels, since script thread events can come from many sources, which means that all queued tasks must fulfill the Send bounds. When we are queueing a task from the same thread that it will run on, however, this is a poor developer experience—it would be much clearer for the task to take ownership of the non-Send data when it is guaranteed that the task will run on the originating thread.

I can imagine three possible solutions:

1. We create a new type that can wrap a non-Send type and verify that it's only accessed on the original thread. This is very similar to the Trusted type that we use to wrap DOM objects for use in async tasks.
2. We add a new type for same-thread task sources. This type exposes an API that does not require a Send bound, and uses an unsafe type to pretend the task is sendable under the hood when it interacts with the channel.
3. We have separate task queues for tasks from other threads vs. tasks from the current thread. The queue for the current thread is a VecDeque rather than a channel, and when the queue transitions from empty->non-empty we enqueue a task that flushes the local queue.

The third solution appeals to me because it requires no extra work from the API user and requires no unsafe code or lying about types.