AD (Acceptance Deepth): BitcoinEC set it always to infinite, so your node can not automatically fall back to bigger blocks than your EB setting. But the BitcoinEC going to monitor where the longest proof of work (PoW) chain is and providing a warning when your not following longest PoW chain anymore because of your low EB setting.
Personally I see it step in the right direction as well.
https://bitcoinec.info/Will you also have an AD(Accept Depth) parameter like Bitcoin Unlimited?
Instead of Accept Depth we will implement a warning system to alert users if they are not on the longest chain. Implementing AD in the way BU has done appears to be fairly complicated and hard to do correctly, a warning system is simple since we only need the block headers for that.
i still think that non-pool nodes should really utilise policy.H more..
EG Consensus.h node hardwarelimit = something set by the nodes performing its own speed test of what it is physically capable of
for example 8mb
then policy.h is the PREFERED size the network should work with.
EG 1mb today and maybe 2mb on activation day.
whereby pools see all the policy.h (prefered) in the node useragents.
and pools then
set their own policy.h just below what the majority of nodes prefer.
EG 0.999 today and 1.000250 day of activation. and pools then test the water of orphan risk and other unforseen bugs and increment up to 1.999 before the 'majority/minority' preferences kick in
thus a minority would accept the block but have their policy.h altered by warning system