Considering T240696: Make linebreak behaviour consistent regardless of indentation level, the output behaviour for comments would presumably have to change with the introduction of new markup (i.e. multiline list item syntax / multiline comment syntax), since it would no longer be necessary to prefix characters to each line of the output. This would presumably make it easier to introduce new syntax at some point before introducing actions 2 and 3 (or any other action in which a top-level comment is added).

@Jc86035, the list of improvements in this task's description is valuable; I'm grateful you are continuing to maintain it.

2. Creating new discussions/sections
3. Adding a new comment in an existing section without any comments

We are beginning to think about the improvements to the above workflows. As part of this work, we'd value knowing what about the existing workflows stands out to you. More specifically, we are curious to know:

• What issues/point of frustration do you encounter when creating a new discussion section and when adding a new comment in an existing section without any comments? What about these workflows do you think could be improved?

Note: we would value you sharing any stories you have about your experience with the above workflows that would help us to more clearly imagine the issues you encounter and opportunities for improvement you see.

In T239978#5795952, @ppelberg wrote:

As part of this work, we'd value knowing what about the existing workflows stands out to you. More specifically, we are curious to know:

• What issues/point of frustration do you encounter when creating a new discussion section and when adding a new comment in an existing section without any comments? What about these workflows do you think could be improved?

Usually any issues I have with creating new sections would be specific to the content of the new section. I typically use the new section button for level 2 headers and manually type level 3 headers, although in creating a discussion page I would typically type at least one level 2 header. Sometimes the section creation happens through templates like {{welcome}} and/or through tools like Twinkle. Twinkle is quite tangential to this project, but I think it's worth noting that it does make certain generic workflows a lot faster and generally more pleasant, and a lot of those workflows involve new sections on discussion pages.

My main issue with the new section workflow is probably that the new section button is usually at the very top of the page (this is probably why some editors insert new sections by pressing the lowest "edit section" button on the page instead). If you're already reading a discussion, then you probably have to scroll back up to create a new section.

Regarding action 3, I don't actually do this very often. It might happen very occasionally, e.g. on a page where a bot creates an empty section every day, or in a new discussion which the thread starter has decided to divide into subsections due to anticipating that it will become complicated (you know, RfCs, RfA, etc.), but I mainly listed it because (1) it's possible in the current interface and (2) it would be rather annoying if an empty section were enough to break the inline interface. Actions 3 and 6 would both be resolved with the addition of something like an "Add comment" button at the bottom of each section, which is what I had in mind when I was writing the task description.

If you're looking for features to implement, I think it would be worth exploring a few other avenues in addition to asking experienced users what they want, since it might not give you the right answers. The simple bureaucratic things that involve new sections are largely handled by Twinkle (or VisualFileChange, etc.), so many experienced users might not actually use the new section button much at all. As a result, for example, users would probably avoid suggesting things that Twinkle takes care of automatically, even if they would be frustrating to deal with without Twinkle.