We, the authors, felt that trying to design everything at once was too large of a task.
Perfectly reasonable position.
We decided that we would choose to pursue one half of 2D Graphics I/O and that input meant and means very little unless there is some definition of what the user's input is in relation to. Just as if a user simply typed into a console without any initial prompt or resulting feedback.
Sure, although I wouldn't diminish the individual importance of input as much as you seem to be implying.
It is, of course, possible to design an input API first, but until that API relates to some output that the user experiences, it has no tangible meaning.
Right. But..
It is simply keystrokes, mouse or touch movements, or clicks or taps. Meaning could be assigned to them in some way by users (viz. the theremin), but the input would have no ties to anything other than a blank screen.
You seem to be asserting that a screen is the only "meaningful" output with regards to feedback of input. The multitude of force feedback devices, light "bulb" indicators, heat surfaces, audio generators, scented vapor devices, nerve stimulation, etc would seem to indicate otherwise.
As such, we decided to focus on output first.
Understood. But can you please provide the actual justification in the paper of why you made that choice instead of the demonstrably inaccurate one of API interdependence mentioned in 0.1.1p5? As it will avoid future arguments like this one :-)
If an input API had been designed around R6, it would've required serious modification in order to fit in the the current output API.
This statement worries me to no end. There are plenty of industry examples of input APIs that don't depend on the design of the output API. And I would consider such an interlocked design choice counter to well established separation of concerns design principles.
That said, feedback from the committee has resulted in many changes to the API, most recently from the San Diego 2018 meeting, which led to the creation of the command lists feature. (No review of P0267 took place an Kona 2019).
I must have been really tired that day as I don't remember command lists coming up :-\
All of that said, I do have one item of reference material at hand that supports our decision. The organization of Computer Graphics - Principles and Practice, 2d ed., Foley, van Dam, et al., Copyright 1996 Addison-Wesley Publishing Company, Inc., Reading, MA. (Apologies if my citation format is incorrect). In it, Foley, van Dam, and the other co-authors address 2D graphics output first and only after that is finished (along with a brief foray into 3D graphics), i.e. the first seven chapters, do they begin to address input (chapter 8...).
Hm, I lent my copy of that one to my work library so I can't look it up right now... But sequencing of learning material doesn't correlate with API design dependence.
But it really was just a choice, one made long before any of us happened to have a copy of Foley and van Dam in reaching distance. I hope that I respectfully stated the reasons we chose output first. If my response does not seem respectful I sincerely apologize and ask that you forgive me. I've been awake for well over a day just now (the mailing deadline was almost 12 hours ago and adrenaline has been flowing through me ever since!).
It was perfectly respectful and well explained. Just doesn't address my concern. Which is essentially that what you just explained as the rational is not what's in the paper. And no worries.. many of us have been in that same adrenaline infused position :-)