See above:
At the moment there is already ongoing work to make the “Swiss subnet” (i.e. a geographically constrained, reduced replication subnet) possible. One specific issue is preventing a potentially corrupted subnet (more likely with lower replication / lower decentralization) from minting cycles and sending them to other subnets.
There is indirectly related work already happening on supporting references in blocks instead of full payloads; and on canister messaging scalability. Both of which will eventually allow for higher throughput and lower latencies, opening more possibilities for canister migration / grouping and autonomous capacity management.
Regarding the specific issues of static subnets and the requirement for homogeneous hardware, my personal opinion (and it’s just that, so take it for what it is) is that they are core to the design of the protocol, so they will be difficult to change.
I guess it also depends on what you mean, exactly. Specifically, “homogeneous hardware” as in “equally powerful machines” is needed in order to avoid long tail latency: if half the machines on a subnet are really slow, then they dictate the speed of the subnet and they waste capacity on the other half that could do more work. If you mean “homogeneous hardware” as “a limited set of tested and certified hardware configurations”, that is partly the same as above (e.g. a 5.6 TB SSD is not the same as any other 5.6 TB SSD) and partly it makes it possible to manage a fleet of thousands of machines without excessive manual intervention (e.g. reasonable BIOS settings enforced automatically).
Same with “static subnets”: it could be taken to mean “NNS proposal required to change membership”, something that I’m sure everyone would like replaced with some sort of automatic process to monitor and replace unhealthy / misbehaving replicas (which may or may not be the “autonomous capacity management” mentioned above); if you mean “periodically rotating replicas in and out of subnets” my personal opinion is that it (1) doesn’t help much with security and requires a lot of bandwidth and (2) once you have the automatic process above, it could be trivially implemented as part of that. If you mean it as (something I’ve seen mentioned every now and then) hiding the identity of the nodes making up a subnet, that’s totally unrealistic; the boundary nodes need to know the membership; and even if they didn’t, one could follow the traffic: either you send every huge payload to every single replica on every subnet, in order to hide which ones actually need it; or you can track which ones are getting the payload (if you have access to a single replica). So it’s security through obscurity at best.
To summarize, work is being done, partly on some of the issues themselves, partly in preparation for addressing others. And there are ideas and plans to address most of the issues that can and should be addressed. It will just take time and effort.