I'm not sure we're talking about same thing. I refer to usage of OPCODES which use block height such as OP_CSV.
on the BITCOIN network you can lock value.. and with enough confirmations. its immutable thus very strong.. where locktime is still workable.. and that lock does follow rules. (not sure how long that lasts before core devs soften that rule too.)
however on LN.. which you must treat as a separate network.. when creating channels where a SUPPOSED uxto is used to then create a child transaction that is then called a commitment. the rules on the LN side are WEAK AS F**K and not really rules at all. and yes the LN devs blame user error for accepting a channel open session with zero confirm txid as the funding. and close session with bad unlocks as user error, even though its devs fault for making such a crappy project with such lack of rules, lack of auditing, lack of controls. lack of checks
the reason i bring it up is becasue you seem to care less that bitcoin devs already did mess with bitcoin transactions. but dont want them to mess with things that can affect a broke OTHER network.. which i found amusing and strange, ..and after soo many months/years of chances you have yet to learn how broke LN is to realise its not worth caring about as something that does not securely secure/hold value. but just presumes to
just skip a few months/years and come to the realisation that LN is broke and a completely new subnetwork bridge needs to be created from scratch to service bitcoiners. rather then waste months trying to hope bitcoin does things to entertain and recruit lightning lemmings
LN has many many issues which is why more people have decided to avoid LN and use other subnetwork bridges to lock their bitcoin value to.
FYI, i only mention LN in first place because AFAIK LN is most common application/usage which rely on block height. Other than that, i only see people discuss nLockTime and OPCODES which rely on block height as HODL option, inheritance or organization which have specific spend/security rule.
what bitcoin devs need to do is stop with the radicalisation of sponsorship deals to just make bitcoin messy to promote corporate patented subnetworks as the saviour. and actually get back to making bitcoin efficient. where every byte of a tx counts and has purpose where actual checks are done. as was the case years ago
idea's such has messing just with difficulty lasts 2 weeks.
idea's like messing with block per adjustment and thus reward amounts per block to compensate to try to force it to last.. overall messes with too many other things including the scarcity and value proposition. thus not the fix
the real fix is to get code to actually check tx data like it suppose to do. as that was the integrity promise of blockchains. to have data which all fullnodes fully verify and meet standards
I don't expect usage of weight/vB unit will be removed anytime soon, at least until hard fork which increase max block size limit.