But the point is that once someone does that then we are back to hot miners again, no? being inefficient simply means that it will be that way temporarily...until it's worth someone's while to do something about that.
Also, if we go with an algo which several or many other coins go there will be yet another hard fork down the road because, like it or not, asics will be developed for that too. Even one fork can be extremely dangerous for a coin & this will be Digibyte's second so rather than just jump on the bandwagon of the algo of the minute I hope (and believe that Jared is in fact) taking his time to make sure this fork will secure the network for a long time to come.
I see your points, but with regards to your first point, I don't see where the mining program and the algo being mined are related. If someone comes up with a more efficient mining program for GPU/CPU use, that would be good news for the traditional miner. The only problem would be if ASICs were to somehow implement that program. At that point you simply throw in a double checkpoint, or whatever else small program change that the new ASIC did not anticipate, and you've rendered them obsolete for your coin. If that isn't enough, then you go with the "big guns" and implement those big changes you've been working on for months like PoS and/or PoT and/or whatever else you've got up your sleeve. Software is always faster and easier to change than hardware.
With regards to your second point, I agree that the more there are of you using the same algo, or same "strain" of algo, the more succulent that group becomes in the eyes of ASIC developers, and, obviously, the smaller the group, the opposite. On the other hand, we've got the principle of "strength in numbers" with more devs working together to further develop a mutually agreed upon standard when dealing with a larger group. There are two sides to that coin.
I think I completely agree with you that even a small fork can be dangerous, but there comes a time when your back is up against the wall, and you've got to do something. That's why I'm minimalistic with my suggestions, and why I stress leveraging the threat of going head to head with any future challenges from potential ASIC manufactures. It's all about buying time, and then doing your absolute best, but with baby steps as it were - those who go "all in" very often get their heads handed to them.
BTW, on the efficency front, something I didn't mention earlier was that I was mining DMD with cgminer before the fork to Groestl and continue to mine it with some machines now (but with today's price crush, that might not last much longer), and my coins mined amount per scrypt adjusted Mh/s since DMD settled down after the change (with a similar scrypt adjusted network hashrate and diff) is exactly the same as before - same identical test machine, same network hashrate and diff, and the long term average is the same. Also, I've been mining EXE (scrypt-n vertminer) side by side with DMD (diamond version of the groestl kernel sgminer) for the last 10 days or so, and the output in BTC terms is almost a mirror image as well, with the difference being that I've got a 45% reduction in electricity costs with DMD. That's what I consider to be more efficient. That's first hand experience. You can also go to coinwarz, of course, and enter real time hashrates and electricity costs, and see for yourself that even the best scrytp coins (14 day average screen) aren't even making those levels of BTC equivalent output to begin with (leaving electricity costs completely aside), so you could say that sgminer is super-efficient compared to cgminer on those coins.
Frankly, IF you're going to make a change, it looks like a no-brainer (always adhearing to the KISS principle), and if you don't, it looks obvious that you're sentencing your miners to higher electricty costs, over stressing of their equipment, and an eventual ultimate defeat to the ASICs as they drive the coin's value to zero in the process.
