uos.dupterm() behavior in underspecified, implementations broken
While not directly related to HW API, https://github.com/micropython/micropython/wiki/Hardware-API#os-module-additions specifies os.dupterm(), used for:
os.dupterm([stream_obj]) get or set duplication of controlling terminal, so that REPL can be redirected to UART or other (note: could allow to duplicate to multiple stream objs but that's arguably overkill and could anyway be done in Python by making a stream multiplexer)
Unfortunately, this description is not clear/detailed enough, or alternatively, current implementations of it in stmhal and cc3200 ports are not general or just broken. First of all, it should be made clear if the talk is about duplicating "controlling terminal", or replacing it. If there's talk about duplicating, then there should be immediate talk about non-blocking streams. Otherwise this line https://github.com/micropython/micropython/blob/master/cc3200/hal/cc3200_hal.c#L187 will simply hang the entire REPL, as it will wait until a character is available on that particular stream, ignoring all other input sources.
And then if there's requirement to non-blocking streams, it should be kept in mind that all other REPL sources should be non-blocking too, otherwise standard source can block custom installed one. But requirement of non-blocking sources is merely a minimal condition to get it all working, but working quite inefficiently and requiring weird workaround to not make it burn CPU cycles (and a battery of battery-powered device), e.g. https://github.com/micropython/micropython/blob/master/cc3200/hal/cc3200_hal.c#L196. So, next step is making requirement that REPL sources are pollable, and actually poll them.
That's quite a bunch of requirements to get it working in the general case, sure.
[ESP8266] No non-blocking read on uart0 if dupterm is active
As far as I can see, there is no non-blocking way to read the input from the uart0, if this uart is also used for REPL through dupterm.
In version 1.9 and before it is possible to use the UART.read() function for this, however since commit afd0701bf7a9dcb50c5ab46b0ae88b303fec6ed3 the uart buffer is bypassed when UART 0 is used for REPL, so that UART.read() will never receive any data.
The input data is now directly put into the stdin buffer, which has (as far as I know) no function to check if any data is available.
The only workaround for this would be to disable dupterm for the uart0 while intending to read data. Yet, this is somewhat inconvenient, because then print() also won't output any data on the uart.
I think, the best option is to add a non-blocking read for stdin (or at least a way to check, if data is available for read).
This is not the same as a non-blocking read on the uart, but for most applications, this should be sufficient.