Here is my constructive comment: unless a hard cap limiting the increase over a certain period of time is coupled to this proposal, any such scheme is utterly broken and can be trivially gamed by miners intent on controlling the blocksize.
Any such proposition is not viable given that it provides no consideration for the externalization of the cost to the nodes and our focus on keeping Bitcoin decentralized.
The consideration given is that, unlike the original proposal, this one doesn't double the blocksize. It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.
This is what cuts to the heart of your misunderstanding; no-one
knows which rate of blocksize increase "will allow nodes to keep pace", there are too many variables and too many unknown events yet to take place. If your approach is based on faulty modeling/assumptions, I don't know why you would expect people to take it any more seriously than the most egregious other examples of the same mistake (including BIP100, 101, and 103).
I think the misunderstanding is even deeper than this.
Flexcap proposal in general are an attempt to accommodate demand and optimize fees for miners. This to me is a non-starter when attempting to design the system with security and decentralization as our main focus.