[Technical Question] Why do Hot Wallets (Phoenix, AQUA) warn against importing external BIP39 seeds, even if they are "clean" BIP85 child seeds?

I’ve been thinking about a specific security/interoperability setup and wanted to get some technical insight into why certain wallets throw "compatibility warnings" during the import process.

The Hypothetical Setup: Suppose someone uses a Coldcard Q to generate unique 12-word seeds via BIP85. The strategy would be to assign a dedicated index to every hot wallet to keep them isolated:

• Index 1 -> Dedicated to AQUA.
• Index 2 -> Dedicated to Phoenix.

In this scenario, these seeds are "virgin" entropy. There’s no transaction history and no "noise." Mathematically, that 128-bit integer is just as random as one generated by the app itself.

The Friction: However, when attempting to "Restore" these BIP85-derived phrases into Phoenix or AQUA, the apps often trigger a warning stating: "Only seed phrases generated in this app are compatible."

My Questions: If a 12-word mnemonic is simply a human-readable representation of entropy, why does the software care about its origin?

1. Derivation Path Complexity: Is it possible that Phoenix/AQUA use non-standard derivation paths for Lightning commitments or "swap" mechanisms? If the app expects a specific internal structure, could importing an external—yet clean—seed lead to a loss of funds or "ghost" balances?
2. The "Safety Net" Theory: Is this warning just a "legal/support" disclaimer? It feels like it might be a way to prevent users from importing 10-year-old Legacy seeds and then flooding support tickets when their balance shows as zero.
3. Real-world Experience: Has anyone actually ignored these warnings and used a BIP85 (or other external) seed for Phoenix or AQUA successfully? Are there specific derivation requirements these "smart" wallets have that a standard BIP39/BIP85 flow might miss?

I'd love to hear the technical "why" behind this. Is it a genuine risk of fund loss, or just UI hand-holding?