I'm not sure exactly how this ["flat" or "simulated"] scheme would work but it's also very easy to break the public key derivation property when you start using hashes for the coefficients.
It's one of those problems were, when you solve one thing you break something else.

We don't even really need a hash function for generating coefficients. All we really need is some way to map a child index to a vector of coefficients in such a way that two distinct child indices are unlikely to map to the same coefficients. Even if the coefficients are completely predictable, an adversary still has the problem of solving a system of t
This "flat" scheme is dumb anyway. It really only applies when the master public keys are public knowledge, since they're always needed to generate descendants. (Previous post edited to include this fact.) In that case, all HD wallet trees are equivalent to a single-level tree in the sense that there's no significant difference between a depth-three child m/x/y/z and a depth-one child m/(xyz) where (xyz) is some way of encoding the three indices x,y,z into a single index. (Hence the name "flat".) In order for a multi-level hierarchy to be functionally distinct from a single-level hierarchy you need the property that each subtree can pretend to be its own separate tree and doesn't need to know anything about its ancestors (ie. the master public keys are no longer public knowledge). But the "flat" scheme doesn't have this property. I shouldn't have mentioned it.