WAIT WAIT, Really?
When is this estimated to be completed? Currently I have to spam raycast to find floor positions and make the objects remain on the floor.
Could you guys add to that list a way to keep objects some studs from ground? Will be really helpful too… 
EDIT:
I skipped something:
Thanks for this as people in my game can currently unequip tools in such way. (Hopefully this change doesn’t disrupt games that uses such feature though).
I want to add that Wireframes do not render on Mobile devices.
Yes, that’s one of the fixes!
The idea is that we should naturally be be able to change this without disrupting anything:
If you have a custom backpack: There is no backspace on mobile, so if unequipping was important to your game there already must be some other way to do it for mobile players to use.
If you don’t have a custom backpack: People can just unequip using the backpack button.
Thank you for the fixes! Is there any plans on when the bug where layered clothing cause lag when changing unrelated part properties will be fixed?
Reference:
Should I be concerned about this?
GetDescendants will return the same runtime value, change is only for Luau static analysis to be more precise.
But this will actually not be enabled in current release because of a different small issue with it.
Yeah, I’m super curious about this as well. I wonder what this means
When I added my own inventory bar UI, I had to program tools to detect when Roblox returned them to the backpack and fire a RemoteEvent to re-equip themselves. Soon (whenever this goes live), I’ll no longer need to use this hackish workaround.
local example : number = 1
local array : {string} = { "hello", "world" }
…and I know that you can use a vertical pipe (|) to indicate that a variable may be one of multiple possible types, and a question mark means that it may or may not be nil, but what do the backslashes indicate?
PerAxis and the backspace change for tools are both incredible, thank you so much!!
You can ignore the slashes, it is just a bug with release note generation where {} ended up with ‘escape sequences’ like \n \t etc.
Really sad, two release notes today and they still didn’t fix the major bug causing a lot of games that rely on animation events to break. There is no provided workaround for the time being until it is fixed either.
I cant wait for this to come out I have been waiting for ages as force equipping lags low performance devices and it’s even more confusing for switching tools…
What exactly can we do with this? Will we finally be able to use keycode without worrying people having other sorts of keyboard layouts as AZERTY?
Do the VR camera adjustments apply to the core scripts only, or does this affect our scripts too? I have prototypes that rely on the ability to rotate the camera such that the horizon is intentionally not level.
I understand that keeping the horizon level is generally a good practice to follow so that people don’t get motion sick, but if this is a safety measure being implemented at the engine level, then I would prefer that games have an ability to bypass it as a way of indicating that we promise we know what we’re doing - some kind of checkbox or enum, perhaps.
KeyCode is just an example, nothing is changed with keyboard input handling. There was just a minor bug with editing enum attributes when they had a very long value list and KeyCode was the most obviously impacted.
for _, desc: Instance in a:GetDescendants()
I don’t have much else to say that would affect me but yeah all-in-all a decent update 
As others have already mentioned here, I am super happy that backspace can now be ignored when using tool instances - it was worth making some noise about that when tools were last updated!
Creating a custom tool system is pretty hard. Tool instances already provide a great wealth of API and internal code to make them work, as well as how tied they are to the engine, but this one thing made me move towards putting the effort to build those custom systems instead. It felt absurd to build an entire system just to void out a single behaviour.
It’s also nice that the change can be made naturally so it’s not disruptive to experiences that still wish to retain that behaviour and works better for other experiences that otherwise create custom backpacks but want the benefits of the Tool instance. Much appreciated for that one.
Final thing is a thank you for removing the deprecation off of DevEnableMouseLock and EnableMouseLockOption. Someone did a really good in-depth analysis in a previous announcement thread as to why the proposed alternatives were inadequate.
