What trade-offs does increasing Kaspa's posterity header frequency involve?

Storing Kaspa's posterity headers once per hour instead of at the current interval would reduce the time needed before a PoChM can be generated, cut the complexity of a related verification step by roughly 40%, and shrink the size of a PoChM. Currently, posterity headers serve double duty as pruning headers, which keeps the design compact. Separating those two roles to support hourly storage would require adding an extra field to each header, pushing the header size to 312 bytes, and the engineering work is described in the proposal as more complicated than the rest of the KIP combined. Understanding this trade-off matters because it illustrates how Kaspa's developers weigh proof-generation speed against real implementation cost when evolving the protocol.