That is incorrect. USAGE COMP will use binary, with the number number of bytes depending on the number of digits in the PIC. COMP-1 specifically takes 4 bytes. COMP-3 uses packed decimal (4 bits per digits).

To me it make sense that completion for program P should be handled by program P itself. That way, completions are unlikely to get out of sync with the application, and the completion handler can use the same option parser as the application. A way to do this is to use a special "hidden" switch to request completion.

Specifically the DomTerm terminal emulator (https://domterm.org) handles its own completions. Bash allows you to register a command that handles completions for some other command. The following tells bash that to handle completions for the domterm command it should call domterm with the magic "#complete-for-bash" option followed by the existing line and position.

    complete -o nospace -C 'domterm "#complete-for-bash" "$COMP_LINE" "$COMP_POINT"' domterm

I don't know how to do something similar for other shells; suggestions welcome. Some other shells (such as Fish) include help text as part of the suggested completions. Handling that would require a more complex protocol. Perhaps one that returs a result in JSON format?

If a such a protocol were standardized (perhaps invoked by a "#completions-as-json" option?), we just need to solve a final piece of the puzzle: How does a shell know if a command understands the "#completions-as-json" option? My suggestion is that we define a new keyword-value pair in the "desktop" file specification; the shell would search for a P.desktop file,

A rather modest enhancement to the vt100/xterm escape sequences would be a mode where screen addressing would be in terms of logical characters and logical lines. The application should not need to know the width of characters or how lines are broken into screen rows. This makes use of variable-width fonts practical - which is necessary for decent rendering of many scripts.

DomTerm's display engine (https://domterm.org) does support lines containing a mix of monospace and variable width characters, and know how to wrap such lines. I'm working on long-term replacing DomTerm's native display engine with xterm.js (for speed and other reasons) which requires making xterm.js more versatile.

Some REPLs have nicer interactive features (such a completion than others). Some REPLs have nicer or more powerful syntax or different data types. But as longs as you have a Read-Eval-Print-Loop it's a REPL.

Many languages in the Lisp/Scheme family have some kind of inheritance or interfaces, including Common Lisp, Dylan, Racket, Kawa, and many more. However, this hasn't been standardized for Scheme. R7RS-small has a mechanism to define new data types (records), but they were limited in functionality to C-like structs.

I (and others in the community) felt (and feel) that it is premature and unwise to add a bunch of new libraries for new data types until or unless we have some kind of framework for inheritance or interfaces. Others in the community (including the former chair) felt this was unnecessary and perhaps inappropriate for a language with the goals and history of Scheme.

There is no clear right answer or consensus for how to go forward, which is part of what caused things to bog down.