By a technical product roadmap I mean a document with the following properties:
The first and last points are the most important ones, because they ensure that people will read the roadmap and agree on the priorities that it describes. The roadmap should therefore not try to answer every question related to user experience and implementation. Instead, it should have just enough information to give the reader an impression of what the priorities are, how the product will behave and how that behaviour will be implemented.
Note that besides user workflows a milestone may also describe purely technical tasks. The intention should be though to direct all work in a milestone to a common goal that is summarized in the milestone title. Milestones that are upcoming should not have obvious gaps in explaining how the product will behave or leave important implementation questions unanswered. On the other hand, milestones that are further in the future will be more sketchy.
I will use the example of a website that allows users to share lists of dance move videos. The website can be used by people who want to learn how to dance. One of the product requirements is that some videos should not be made available to all users. This is because some dance teachers make videos available to their students but do not want these videos to spread to the whole internet.
As you can see, the glossary already explains several things about the application. It introduces important concepts, and to a certain extent, the behaviour of the application follows from these concepts.
Ideally, every step in a milestone contributes to some overarching goal that is summed up in the milestone title. Usually a milestone describes a viable version of a workflow, but not the ultimate version. In future milestones the workflow may be updated and refined. For example, a future milestone can state that move titles are rejected if they contain disallowed words.
Point 1.1 of the milestone illustrates how certain details are left out: it doesn't say how the user can send a request to become an uploader. Maybe there is a contact form, or maybe there is an email address. Since this information is left out we can conclude that this topic is apperently not important enough to be detailed here. Similarly, in point 2.1 it's not stated which fields are required and which are optional, because this is not essential information for the roadmap. If a user story is added to a Scrum sprint for this feature then it probably will specify this information.
In point 3 we don't repeat the fields of a move, because that is already mentioned in point 2 and we expect the reader to be reading the whole milestone. This is an important difference to a backlog with user stories that must be more self-contained.
Point 5 shows an example of mixing implementation details (5.1) and features (5.2). In my opinion it's important to add key implementation decisions to the roadmap because the whole team should be on the same page about them. If the decision to use immutable data and domain events is controversial then it helps to make this information visible in a place where people can discuss this and sign-off on it before the implementation starts. Without this information you cannot claim that the team is aligned on the plan. Note that it's enough to outline the technical approach, the details can be described in other documents.