As far as priority goes, most interesting cases will have priority based on the data in the read, except for this specific case of a done chan el and a data channel. I used that pattern at first but have been moving away from it. To be sure i am mostly writing long lived processes with fixed pools of worker go routines and either never exit or exit based on WaitGroups determining the work is all done.
Yes, it (the lack of deterministic-select) is only annoying for several special cases. For most cases, it doesn't matter whether or not the default behavior is deterministic.
Wouldn't it be the case id one worker was pulling work asynchronously delivered from two places? I only use one go routine / one channel myself, but the name select itself very strongly implies it is a yield type operation where any of a number of async actions can wake it for their callback to run. Albeit without a callback syntax, it is async and better be fair.
In fact, in practice, sometimes, I do hope one specified case has a higher priority than others if they are all non-blocking.