I don’t know of any PR for this issue.
The return value comes from the OS send call. Since SCTP is packet oriented it got to share code in inet_drv.c with UDP. For UDP this value is never returned since it is allowed to loose packets and if the OS buffers should be full the packet is dropped and an OK value is returned. For SCTP I guess it happens in some overload situation when the OS is out of SCTP send buffers…
When this value is returned, inet_drv is supposed to insert the file descriptor into the VM select/poll subsystem and await a callback that it is time for a retry. But the UDP code in inet_drv is simply not structured for that, so when SCTP was added we took a shortcut and returned this value back to the Erlang level. Since it very seldom happens we postponed the problem for a rainy day.
The new socket module is better structured to handle this, but here SCTP is very incomplete and untested. It might still be easier to complete the SCTP support for socket than to make the UDP code in inet_drv select/poll aware. But there may be other options. One bad option is to loop over a timeout in Erlang if this happens…