What we have now is:

• unix port lacks builtin polling mechanism, instead select.epoll is implemented in micropython-lib. epoll() is Linux-specific (but the most efficient after POSIX select() and poll()).
• stmhal has builtin select.poll(), which roughly corresponds to Python3 select.poll() (e.g. upstream poll.poll() takes timeout in milliseconds, which is very convenient for us). One glaring incompatibility is return value of poll.poll() - instead of list of tuples (fd, flags) it returns just list of "fds".

Proposed:

1. Make stmhal's return value be compliant with upstream API (and read/write ready flags are important on their own). If there's concern of efficiency, return list size can be limited (micropython-lib limits it to 1). Further "dangerous" optimization may be to have static tuple and/or list object and reuse it (user app should not cache any such values, that's fair assumption, and well, nowhere poll.poll() description says it returns fresh objects ;-) ).
2. As a stopgap measure, micropython-lib to provide select.poll implementation in terms of select.epoll. Next step is to actually implement select.poll to improve portability.
3. As a step forward, we actually should look into providing upward path to support "selectors" module, which allows to specify "callback" data together with "fd". micropython-lib actually implements such extension already. So, for step 1, I'd suggest to return 3-tuple right away, even if last element is None.