Work has resumed at something like a full pace, and prior to implementing and testing it, I believe from stty on down it's correct except for a new name for gtty, which has been modified to return the possible arguments to stty that the *implementation* will take. That is, it's not in its contract to know if it's running on Linux that a certain bit is ignored, or that a certain serial port can't for example do RTS/CTS flow control (that's not in POSIX, but is in both Linux and OpenBSD and it's conceivable someone will have a device that uses it). gtty is has historically been used for other things, is too close to getty(), and doesn't really describe what this procedure does, we can be more verbose.

After a bit more work it should be ready for a new draft and additional sample implementation work. See here for current version: https://htmlpreview.github.io/?https://github.com/hga/srfi-205/blob/master/srfi-205.html the changes to the document are in the "Low-level terminal manipulation" section, see here for the commits: https://github.com/hga/srfi-205/commits/master

I'm now going over the with-* and without-* section of procedures, such as without-echo for entering passwords that uses stty and I do not like what the last two sentences in the first of the two following paragraphs does, and think "from a specified place" is redundant (emphasis added):

The following procedures conform to an implementation model that represents how they may be implemented. A state object is a hidden object that represents the complete state of a terminal line as retrieved by tcgetattr() and set by tcsetattr(). An implementation of this SRFI maintains a stack of state objects; a new element can be pushed, the top element can be popped, and the bottom element can be retrieved without popping it. The stack is initialized with a single state object representing the state of the terminal when the program starts. In practice this may be done on the first call to any of this section's with-* or without-* procedures.

The procedures use dynamic-wind when executing their proc argument. In the before-thunk the current terminal state is fetched from a specified place and is pushed on the stack. Then specified flags are turned on or off, and the terminal is set according to the resulting state. In the after-thunk a terminal state is popped from the stack and the terminal is set accordingly....

As I interpret the language, this bottom of the stack state-object should never be accessed or used in any way except for the special case of with-cooked-mode which allows you to for example spawn a shell while in with-raw-mode. But I don't see why it shouldn't use the first state-object created by with-*-mode in that situation, and if the stack is empty, grab the current terminal state and push it onto the stack. For example the lower level procedures might have been called to change the terminal's settings between the time the program is started and when any of these with-* or without-* procedures are called, and that might be the desired state to resume for a sub-shell.

Is there any circumstance the specified place won't be the device associated with the port that is given to these procedures?