b. not have the cludge of 1mb base 3mb witness. and just have full open access 4mb for transactions to fully utilise
This reeks of potential technical debt. It's something you've proposed on numerous occasions for the last few years now, but have never fleshed out. How, exactly, do you propose enacting this? Don't just give us the wishlist, tell us step by step what this option actually entails.
the technical debt already exists.. its the cludge they already put in it to get segwit working
the cludge sipa added when rewriting bitcoin to make segwit work (the cludge) reeks of technical debt because it is.. however not having the cludge and getting back to simpler straight forward block checks, proper coding proper byte counting, proper validation lessens/undoes the technical debt
yes there are many lines of code in different sections that deal with the legacy*witness and serialised / witness.. and all the other cludge of vb and weigh unit manipulations of byte counting.. but thats cores own fault for creating the cludgy way of trying to slide segwit it..
getting back to clean code where its a unified 4mb where both legacy and segwit can be side by side under a unified single merkle to allow more transactions per space will require undoing the cludge (technical debt)