The use of x-only pubkeys is indeed a technique that saves space by only including the x-coordinate of a public key, as opposed to both the x and y coordinates. However, this simplification comes with complexities when implemented in certain cryptographic protocols.

Multisignature schemes, such as FROST or MuSig2, rely on careful coordination and combination of public keys from multiple participants to create a single, valid signature that represents a group agreement. The crux of the issue with x-only keys in these contexts lies in the nuances of how signatures are composed and verified. For example, the MuSig2 protocol addressed concerns that arose with its predecessor MuSig1 regarding the possibility of rogue key attacks and other vulnerabilities.

Key aggregation, which is fundamental to these multisig protocols, must be handled correctly to ensure security. With x-only pubkeys, extra caution is required to maintain the integrity of the aggregated key, as the omission of the y-coordinate could potentially lead to ambiguities during the verification process. These subtleties must be meticulously managed to prevent any weaknesses in the multisignature scheme.

The discussion around x-only pubkeys highlights the delicate balance between optimization and security in cryptographic design. While they present an attractive method for streamlining key representation, developers must be vigilant about the implications on the protocols they are used with. It is not merely a "useful trick," but rather a design choice that necessitates a deep understanding of the associated multisignature framework to avoid introducing flaws into the system. The conversation serves as a reminder that even seemingly minor optimizations can have far-reaching effects on the security and functionality of cryptographic systems.