Meta issue, review discussion on closed issues and confirm the resolution is satisfactory

[alerque]

I'm going to close a couple issues that have long-running discussions on them with unconfirmed resolutions. This is and issue triage/housekeeping decision. I'm trying to work out how to funnel the time I have available into what has to get done to cut releases and it's really hard to do when I think something is addressed but getting third party confirmation on it takes months out of sync with when I have time.

This is not to say the feedback isn't valuable or the issues can't be re-evaluated. Rather than just closing them and leaving them to fall out of the news feed, I'm going to note them here checklist style. My hope would be that one day when @Omikhleia gets a chance we can confirm that the resolutions are actually satisfactory or else note that something is still off and re-open the issue (or if appropriate open a more focused issue) for further evaluation.

I'm happy to make adjustments to make 3rd party development of packages and projects easier, but I also have to get my own projects out the door. I'm only closing these because I legitimately think the issue is addressed, but with the caveat that I know this is a case of "it works for me" and am happy to re-evaluate if evidence turns up that it doesn't address more general use cases besides mine.

• [ ] #2041 (Most especially the list package changes, but of course anything else related to #105)
• [x] #1974

Also this is an open offer to help with porting libraries to the new APIs represented in new releases if necessary.

[Omikhleia]

You are welcome.

[Omikhleia]

Is losing noindent after chapter and section a new feature?

0.14.17 manual

0.15.0 manual