The concern is that integrating such a mechanism would not only add significant complexity to the system's implementation but also might inadvertently allow higher feerate chunks to meet the incentive compatibility rule designed for lower-feerate chunks. This approach could lead to unintended interactions between unrelated transactions, complicating the validation process.

The conversation suggests a preference for prioritizing incentive compatibility when selecting transactions for validation, rather than focusing on DoS-compatibility. It argues against the strategy of aggregating chunks based on their DoS compatibility, proposing instead that if additional computational resources were available, they should be utilized to search for aggregates or subsets of chunks that offer better incentive compatibility.

A specific rule is mentioned where a child’s fee rate must exceed the parent’s fee rate for both to be included in the same chunk, which is highlighted as a straightforward guideline for wallets. This rule facilitates easier transaction inclusion by linearly arranging child and parent in the same chunk. Furthermore, the dialogue touches upon a scenario involving a high-feerate small parent chunk and a low-feerate child chunk, suggesting an alternative solution of attaching a small, high-fee transaction to the parent chunk to mitigate concerns regarding fee rates without necessitating a higher feerate for the child chunk.

Lastly, the discussion acknowledges the possibility of dropping an entire transaction package due to issues like signature failures or complications arising from recent soft forks, indicating a cautious approach towards handling potential 'malicious' failures within the system.