First, identify every component on the system that either generates heat or has its functionality affected by heat. Now identify the interactions between those (eg, components that are far apart have a reduced impact upon each other - an object at 60 degrees but the other side of the system is less significant than an object at 50 degrees but directly adjacent to the impacted component). Now identify all the mechanisms you have to alter the heat output here, ranging from frequency management to direct throttling to reducing output to powering down the device entirely. Now express all of these things in a static table, leaving enough room for extensibility to handle next year's devices that may wish to expose some interactions or constraints that you haven't considered yet.

HID, on the other hand, merely asks a device to define the set of reports it can generate. It doesn't have to express dependencies. In fact, the lack of a strong mechanism to express dependencies is one of the reasons why more complicated devices don't tend to work correctly with generic drivers - they don't have a way to express their full set of functionality, and so make use of vendor-designed extensions or hardcode that dependency information in the driver. Linux has over 100 drivers in drivers/hid, and if the HID spec were sufficient then most of those wouldn't exist. So in some ways, yes, HID is a good example here - it's a spec that attempted to meet a set of needs, but fell short because reality is more complicated than the original designers envisaged. And thermal management is much harder than just reporting "I have this set of keys" and then sending reports when one of them is hit.