I agree technically on VLQs – you get better code size now and you future-proof a system that in principle will run forever. I can’t speak to schedule issues, but I imagine they are tight. If it helps – and I’ve forgotten the details of the VLQ scheme you are using and of the EOF immediate size issues – but some schemes would let you specify a fixed-size field with unused bits now which could become variable length later when those bits start getting used.
If someone wants to pick up the 2315 ideas in the future I don’t think that EOF forecloses them. Somewhere there is a old PR of mine proposing that EOF code sections not be functions, but modules with multiple EOF-defined entry points and no cross-module jumps, but with EOF-2315 supported inside of modules. We never discussed it much, but something along those lines should still be doable.
EIP-2315 wasn’t seriously considered in part because it I never seriously proposed it again. It’s last-minute rejection simply set my research back too far, and I became content to join a startup doing other VM work and in my spare time get the proposal to where I wanted it and make sure that EOF functions provide at least the same level of init-time validation, which earlier versions did not.