mastercomsBecause that's the server restrictions and you shouldn't be able to bypass server restrictions by default. You don't really get any sort of lower ping, because it shows you a different state than anything you'd get in the future with interp, due to it being extrapolated and/or teleporting client side rather than being what's happening on the server.
Does this mean that, since you are extrapolating clientside, it will become inaccurate if some change was made in the tick (or whatever timeframe it extrapolates), but otherwise it just results in it looking like your ping is lower (I understand it isn't, but it simply looks nicer)? Hitscan seems pretty bad with it (in terms of getting missed/hit shots when you shouldn't) but subtle inaccuracies don't really mean too much for soldier/demo. From playing with it it just seems like your ping is slightly lower, at the cost of some players looking a bit jittery. It's also pretty huge for demo jumping because the inaccuracies are non-existent as the visibility of your own stickies is what matters.
mastercomsAnd now, if the server allows it, there won't be lag compensation issues anymore because this change acts as a forcing function to have correctly synced interp values. So it's allowed in cases where it wouldn't cause any issues beyond just the normal lack of interp.
Was this not possible before? Or has something actually changed that allows for better server net settings.
mastercomsWhat happened before was just a shitty workaround for a client or server misconfiguration. Now you actually have to have both in sync. Furthermore, with higher update rates, it actually improves the behavior of lower interp values because server data can be sent as fast as possible according to the network tick, rather than being limited by the snapshot rate of max 66, like it was before because update rate on its own was bounded by server settings.
Does this mean that server settings can now be adjusted to approach the same visuals as '0 interp' gave, without the jitter? Or is this not achievable with reasonable (performance-wise) settings.
mastercomsSo in conclusion, instead of pretending there isn't a problem, it shows an issue which can be properly resolved for a better result than the previous bypass.
I think it's fair to say it's not intended behaviour, but I don't think that necessarily means it should be removed. There's a lot of unintended behaviour in the source engine being used, if it doesn't cause any issues I don't understand why it has to go.