This update is another super useful addition! Massive fan of these type of improvements that make common tasks much simpler. 
A couple bits of feedback:
A Model:ResetScale() function that sets Model.Scale back to 1 without resizing the model would be useful for situations where you want to refresh the modelâs scale (e.g. updated whatâs in the model)
Setting Model.Scale in studio doesnât respect Collisions (in the Model tab)
Itâs a fairly deep discussion, but because the core architecture of the Roblox engine doesnât support âdependent propertiesâ.
Every property in the engine is supposed to be something that can âfreelyâ be changed without impacting any other property directly. Downstream consumers of the properties like rendering may combine multiple properties to figure out what to do, but the properties are all fundamentally independent from one and other.
A lot of the engine architecture relies on this. Replication takes a advantage of the fact that it can freely change properties in whatever order on whatever timeline to be performant and robust even over a very questionable internet connection. Serialization takes advantage of this, not caring what order properties are written into the file in. Etc.
For that reason you canât have a property like scale that sets other properties when you set it, a method is needed instead. The âScaleâ you see in the properties pane in this case isnât really a property, itâs a fake for editing convenience.
Oh wow, does this mean we can now just scale R6 avatars in-game without having to re-adjust or recreate all the joints, scale accessories and whatnot?
Yes, scaled rigs (R6, R15, or entirely custom) will just work including accessories, animations, etc.
Tools are the only caveat, if you want a tool to adjust to the size of your character youâll have to do it explicitly by calling tool:ScaleTo(character:GetScale()) when picking it up since Tools donât have a contract of automatic size adjustment.
For now weâre seeing how things play out without these to avoid complicating the feature unnecessarily. The current solution is to ungroup and re-group the model if you want to change the canonical factor. If thatâs too awkward or artists need more control in Studio weâll see about more affordances.
Love QOL things like these. Makes development process so much more⌠enjoyable. More times than I can count this wouldâve been a godsend just yesterday.
Is this mainly due to technical reasons? Compared to pretty much any other game engine, Roblox Studio seems to be extremely behind when it comes to lighting. It creates a lot of difficulty when lighting other than world lighting is needed and constrains what youâre able to do when it comes to realism.
The Scale API is otherwise a great unexpected update, thanks!
Thank you so much for this. These have been some features Iâve been wanting for years and now they are actually real. This is amazing work! 
Iâve been waiting for this one - solid release!
Can you scale certain properties of a part such as Height, Length, or Width without scaling the entire thing?
What it comes down to is that Roblox strives to be more dynamic than other engines.
When youâre willing to say âthis is exactly what the level will look likeâ and precompute a bunch of lighting information, it gets way easier to have rich performant lighting. But we arenât willing to say that: A lot of Roblox power comes from striving to be an accurate dynamic simulation of reality that doesnât rely on precomputation and visual trickery to make things work. If we take the âbe an accurate simulationâ approach then that naturally creates a lot of forwards compatibility where Roblox content keeps working and automatically becomes better over time.
And thatâs the TL;DR: If we implemented various lighting precomputation approaches you could create higher fidelity content on the platform now, but you would sacrifice future potential.
Think: Is it a good idea to push the ecosystem towards a bunch of rasterization centric lighting hacks when 10 years from now everything may well be using raytracing which is incompatible with those hacks? These are hard tradeoffs to make a decision on, and so far our choice has been to prioritize being dynamic over being as high fidelity as possible.
I hope that this new scale APL lets me to actually scale anything.
Thatâs literally the entire point of scale? 
Amazing update. Glad I donât have to install a plugin for this anymore. So smooth. Might be an obvious question but, just to know for future reference, if I try to scale a 300 part model in real time, the game will crash, correct? (thinking about implementing the ant-man giant oil rig throwing animation)
You thanked yourself in third-person⌠lol
The particle scaling is a god-send. I cannot stress enough just how fantastic this update is going to be for work flow. Seriously, this is SUPER, SUPER useful. Thank you.
For my feedback, Iâm fine with everything, but I do think instances shouldnât scale when resizing a part, since parts donât always scale uniformly. If someone wants to scale the part and its properties, they could just group the part, scale it, and then ungroup the part, which is super fast still with keyboard shortcuts. That would result in both functionalities being usable as opposed to just one.
Overall, incredible update. You guys outdid yourselves with this one, and I also really appreciate you reaching out to the community for further feedback on it.
Thereâs nothing fundamentally wrong with calling :ScaleTo every frame. It does have the same caching as :PivotTo so you wonât run into floating point issues. Youâll just have to use your judgement because resizing physical stuff in the world is still significantly more expensive than moving it.
The big caveat is that you probably donât want to scale stuff per-frame on the server because the operation will still replicate to clients as a bunch of separate Instance property changes, not as one atomic scale operation.
Per frame resizing of:
Sorry to bother, but I would like to know what is an engine level API? Whatâs the difference between it with the current state of the scale tool?
The old Scale tool was just a bespoke collection of Lua code which was written to work on specific types of Instances. You could copy this code out of the Scale tool and reuse it in a game or community plugin, but this would come with a lot of caveats. For Instance, thereâs no guarantee that that code would continue to work on new types of Instance we add in the future.
Having an actual API in ScaleTo is us providing you some guarantees: That when you call ScaleTo on a Model, itâs going to scale that model in a consistent predictable way regardless of how the engine evolves in the future.
The other aspect is that when you call that API the engine can be a lot more clever about how it handles things, for example allowing packages to scale without modification. With the old scale tool Lua code itâs very difficult for the engine to figure out that whatâs going on is actually a scale operation: All it sees is a bunch of separate property changes happening and the best it could have done was make an unreliable educated guess on whether a scale operation was happening.
Is this contemplated?
Thatâs (almost) exactly what this is!
Though with the caveat that the content has to be in a Model (or temporarily be moved into one). This is a reasonable restriction because models are the Instance that has a 3d reference location in the form of their pivot, and you need some 3d reference location to do the scaling around.
Another reason for this restriction is that the model caches the âoriginalâ sizing for the extent of the session, such that you can rescale the model as many times as you want in the session without introducing a bunch of floating point error in object positions. Itâs better to have only model pay the cost of supporting this caching rather than every Instance type.