Should the max blocksize cap be removed?
According to my reading of the UAHF spec, it has been removed since August 2017.
See;
https://github.com/bitcoincashorg/spec/blob/master/uahf-technical-spec.md
REQ-4-1 (require "fork EB" configured to at least 8MB at startup)
If UAHF is not disabled (see REQ-DISABLE), the client shall enforce that the "fork EB" is configured to at least 8,000,000 (bytes) by raising an error during startup requesting the user to ensure adequate configuration.
Now, if you ask BU, since years the abbreviation EB is described as being a replacement of the blocksize cap. The usage of EB implies that the consensus rules no longer apply to the blocksize. This is enforced by the wording that specifically states this is a user configuration.
This is just my reading, and I guess the ABC client still has code that implies the max blocksize is a consensus rule. But Flowee and BU don't. They see the 8 (and soon 32MB) as just a default for the EB setting (called blocksizeacceptlimit in Flowee).
[doublepost=1526117007,1526116385][/doublepost]
If you remove the cap altogether we don't know what happens at the extreme end of things
In my opinion the ideas behind EB / blocksizeacceptlimit stay valid and are actually used. Miners decide to reject blocks above a certain size. In the Tuesday upgrade miners agree to collectively move their blocksizeacceptlimit to 32MB, while keeping their generation size at 2MB or so.
Which means that the extreme case of an evil miner creating a 50MB block, that will just get rejected.
I want to add that I don't see any inconsistency between the miners using the EB concept on one hand and our communication being based on "max blocksize" on the other because the AD concept was never liked and the collective agreement on the max block size has been an effective way FOR MINERS to get this set for the entire time of the Bitcoin ecosystem.
Using the 2-anual upgrade cycle to set a new limit is just a continuation of this.