Seeing as we’re getting UI constraints Soon™, now might be a good time to add value objects to hold the data types primarily used in GUIs.
I don’t have a specific use case for them beyond them having the same use as the current value objects (cross-script communication, interaction with the end-user, ect), but there’s no time like the present to add them.
I would prefer a replacement for *Value objects, like some ValueContainer abstract class that each instance would inherit from (currently they are all unique instances that inherit only from Instance) or a new ValueObject with a type property that holds a value of that type, or maybe a ValueObject that can just hold a value of any type like a variable can.
I’d love for there to be an abstract class that contains them all, or for there to be a ValueObject, but we’re too far down the rabbit hole to change that now.
How? Deprecate the existing ones and add the generic. Nothing breaks and developers are free to start using a value object that always has what they need.
Well, I’m not sure how easy that would be to implement, but yeah, it’d be ideal.
I feel like these types of classes influence people to make poor design choices when coding…
I feel like FilteringEnabled being optional influences people to make poor design choices when coding. That doesn’t mean it doesn’t have a place.
That’s obviously a comparison between two completely different situations, but its point still stands. My use-case for this is that I’m having to put values in global tables in order to transfer them between scripts, which is less than ideal, so I want this to cut down on that.
Right, because backwards compatibility and not breaking every ROBLOX game ever made is important.
This is basically the entire idea behind ModuleScripts.
Using Values is a bit unhealthy, imo.
Values where useful for networking when RemoteEvents/RemoteFunctions weren’t a thing yet. There are people (@noliCAIKS) who wrote a whole packet networking system using StringValues (and others?).
Using SomethingValues isn’t bad, but it is unsecure with FE disabled. (and with FE it doesn’t allow client > server) (one of the reasons why the leaderstats system is still the same)
In my opinion, having FilteringEnabled turned on by default would be good - it may affect old models and code that people use, but systems made with FilteringEnabled in mind just so works well when FE is turned off, rather than systems made without FE in mind suddenly going onto a FE-enabled place.
FilteringEnabled has become a standard for almost all successful games on ROBLOX nowadays, and you would still be able to opt out of FE if you want to - but it should really be encouraged to use in the first place 
On the topic of *Values, I sometimes use ObjectValues for referencing other objects. It would be good to have UDim2Values and Vector2Values, but I doubt they would be used much - as possibly already discussed earlier. An abstract class to identify these objects would be great, to say at the very least 
value objects, nor global tables, are good coding practices
there are lots of alternatives, try using bindable events!
Getting more *Value objects just because seems irresponsible now that we have Remotes, Bindables, and ModuleScripts.
Getting more *Value objects doesnt hinge on getting UI Constraints.
With the new ValueBass class, I think it’d be a good idea to have these UDim2 and Vector2 types.
I would also dig the class @1waffle1 suggested.
You can argue about making your own custom networking, but in the end Value objects will always be more convenient IMO.
They provide a way for easy-to-understand configuration (no scripting knowledge of data types required), a way to debug your code without restarting a test, a way for beginners to gain a basic understanding of how stuff works when tables are too complex for them, and a way to store data in a persistent, cross-script format.
And no custom code required!
(I don’t mean to make consistency my most used argument, but it’s either all or none when it comes to stuff like this, too.
If you’re going to have value objects at all, you should have all of value types be supported, and if you argue against them because they’re not necessary, then why are they in an un-deprecated state?)
I use UDim2s all the time, and like some other people have mentioned around on social media, they could be really useful to store things like tween values representing the opposite of the object’s current state.