One of the things I am left wondering when reading the spec and some of the issues in this project is the question of what audience this project is intending to target; in fact, what two audiences.
The first is what types of projects. There are a few different major types of software projects. One is libraries, that are intended to be used by other developers, or possibly hosted APIs. Another is server software being delivered to sysadmins, or maybe anything highly technical; the end users are expected to be technically proficient and know a bit about how the software works, but are not necessarily API consumers. The last is end-user facing software; hosted software intended intended for non-technical end users, or desktop or mobile software intended for them.
The other question is who the audience for the changelog is, which is a slightly different question than above. While the audience could be the primary users of the software, it could also be downstream distributors such as package maintainers for software that gets packaged in Linux or BSD distros, or it could be other developers, QA, and tech support within the project itself.
The answers to these questions would influence some of the other open discussions I see on this repo. For instance, issue #2 about which changes should be included. If it's intended for team members who are heavily involved in the project itself, it should probably include all changes like a GNU style ChangeLog, though I think that with modern Git commit message conventions that's redundant, the Git log is where people involved in the project itself should be looking.
Issue #30 is also related to this. It mentions marking internal vs. external changes. Perhaps the idea here is that the changelog is for the internal team, but a user-facing release notes should be extractable from it?
The other audience that isn't frequently thought of, besides internal people and external users, is external packagers. Things like reorganizations of data files or splitting up of single binaries into libraries and multiple binaries, licensing audits, and the like may be important to them.
What type of software this is targeting is also important. For developer-facing APIs, pretty much every change that affects the external API should be documented, as well as any major internal changes that may affect its behavior. For sysadmin oriented software, any data migrations that might be necessary should be mentioned. For end user oriented software, probably only user visible changes and added removed functionality should be mentioned.
However, sometimes a single project is more than one of these things. You may have a hosted service, that has both a programmatic API and an end-user facing interface.
Defining which of these types of projects, and which of these types of users, is in scope for this document would be good. If they are all intended to be in-scope, then there may need to be a decision on how to support all of them if they have conflicting requirements, for instance some changes that are internal only, or some that affect the API while some that affect the UI.
Is the goal to support those through multiple different changelogs, or some master changelog from which each could be extracted?