Maybe we should move these explanations to a more central page, like a glossary, and link the terms there?

Please add a link to the page about responsiveness https://hig.kde.org/introduction/responsive.html

The HIG for Kirigami got merged into the KDE HIG, there are no longer two different HIGs

I don't think we need a disclaimer. And if we want one we should put it right on the start page of the HIG, because every aspect of the HIG is envolving and might change in the future.

Maybe omit Smartwatch and Television for now?
These device types would require a very different UI/UX to Tablet/Smartphone and Netbook/Desktop. Smartwatches needing their own design for the tiny screen size, TVs needing their own design for interaction with a TV remote.

And there are no current projects for Smartwatch and Television I'm aware of.

That makes sense but I couldn't really find a suitable central page for this. Do you have a suggestion for an existing page? Or if a new page is needed, it might make sense to create one for the entire HIG, if it makes sense to put other terms in there as well.

The Smartwatch device type doesn't make much sense for running convergent applications but it would be very interesting for a convergent workspace (e.g. Plasma shell). If the Plasma shell runs on a smartwatch, it would optimize for the tiny screen and only show widgets/plasmoids, focusing primarily on notifications. This is described in the Smartwatch UX (particularly the last sentence of the Optimal UX section).

An interesting addition here, is that since applications can interact with widgets, these applications could show their content on a smartwatch as well, through a widget. But the smartwatch would likely only show one widget at a time, defaulting to a clock widget or something like that, showing notifications as they arrive (possibly auto-hiding them).

The TV device type is intended for things like media centers or presentations (possibly connected as a secondary screen). There was a Plasma Media Center a while back, I'm not sure if this is still active. The design would probably be very close to that of a tablet (as indicated in its UX section), similarly focusing primarily on Application Content, but with some changes to allow interaction with a TV remote instead of touch.

I do agree that smartwatches need their own design but the reason I think they should be included here is to ensure that an application or workspace can transition from one design to the other. This is also what I mean in the next section about going further than just a responsive design. For a smartwatch, the notifications widget from the standard desktop might be replaced with a smartwatch-optimized widget (using the Alternatives system), but everything behind it would be the same.

The intent was to separate what the component is from why it exists. The former describes its functionality, the latter describes why this functionality exists (essentially, this would be the user story).

I've now changed "Purpose" to "User Story" and rephrased it as an actual user story. This also forced me to be more concrete about it. I'm using Susan as persona, since she seems the least tech-savvy persona. So if it works well enough for Susan, it should work well enough for the other personas as well.

On the desktop, this does refer to the system tray where you can also have foreground applications (e.g. Konversation minimized to system tray). I consider this additional functionality in the system tray, not within scope of this component. Access to things like Bluetooth, network manager, notifications, those are within scope of this component. That is also provided through the system tray. This is also needed on smartphones, usually provided in the topbar. Like the system tray, it shows a subset of icons in the topbar and you can expand it to show all icons. So convergence-wise, this indicates that it makes sense to implement this topbar on the smartphone as an alternative to the system tray widget (I'm not sure if this is currently the case).

I've now changed the term to "Workspace Configuration Shortcuts". So I've defined these things like Bluetooth, network manager, etc. as shortcuts for configuring the workspace. I think this makes sense as this is also available in the system settings. But the system tray provides quick access to these settings. But as I explained above, the actual implementation of these common components may not be a 1-on-1 match with what's described for each component.

This refers to the most common workspace configuration shortcuts. I think those apply to Susan as well. These are things like notifications, enabling/disabling wifi or disconnecting your USB stick. These seem like they fit within the scope of Susan's persona (or any user for that matter) and does not imply that Susan (permanently) changed the configuration of the desktop in any way. I added this to the description to make it bit clearer.

The name might need some tweaking since displaying notifications may not really be "workspace configuration". It is functionality from the workspace which needs to be highly visible to the user though. So it fits with this component. But I can't really think of a better name for this. And "workspace configuration" does seem to imply the permanent type of change to your workspace, instead of these "runtime" changes.

Again, the phrasing of the user story might seem overly complex but this refers to very basic functionality. It includes closing the application window which I think even Susan wants to do.

The technical, somewhat abstract, phrasing is needed to concretely define something that is so obvious that Susan wouldn't even think about wanting it. She just assumes it's already there.

I ended up replacing the whole traditional-style input section with an explanation of what it means to have a keyboard and pointing device (which includes the feedback above).

I phrased this as "usually with one hand" since I think this UX should optimize for one-handed control. I elaborate on this in the optimal UX to indicate that it may be unavoidable that sometimes both hands are required.

Ah okay, now I get what you mean. I agree it's relevant for Susan, and I agree it needs a different wording.
"Workspace configuration" really sounds like configuring Plasma, like changing Plasma layout or theming.

Maybe "Workspace actions"?

I now understand what you mean from the examples, but I don't know anybody who considers minimizing a window "configuration", so it needs different wording

It doesn't say "configuration", it says "interaction". In abstract terms, I consider "minimizing a window" to be a change in how the application is shown in the workspace (and no, it's not a configuration). I'm not sure how else to explain this.

The reason I wrote this in such technical terms is because the point of this piece of text is to concretely link the terms used below (UX, Device Type, optimal UX) to how they would need to be used to implement the UI for applications on such a device.

To that end, I also capitalize any words that are technical terms, for which the meaning has been described elsewhere. This should allow readers to understand that it's a very specific thing, that should behave in a very specific way that's defined in the HIG. But if that's not clear, I can lower-case them.

While I agree that your version of this text is more readable, it doesn't give concrete guidance on how to use the information described in each Device Type UX.

I previously called it that, but some of these aren't really physical characteristics. For example, whether a device is used one-handed or with both hands. That seems to fit more with UX Context (which was defined in the Glossary, which is now removed here).

This sentence ("The workspace can be configured to maximize applications by default") is specifically intended to optimize the UX for a more moderate screen size. It doesn't have to be the default provided by KDE but it should be possible for a user to change their own default to this. I'll rephrase it, hopefully that makes it more understandable.