The actual navmesh code is already gone, there is no value in these few lines of code.

Might this still be useful someday for crowd simulation in everything nodes?

Already solved by rB38685b5a3976: Edit Curve: Improve Curve extrude

Task created, and thanks for your patience.

Sure. Will do. But it is the same commits and the same change that is responsible for both behaviours.

@Reiner Prokein (tiles) Thanks for explanation.
This looks like quite different issue, than this one. Could you please make new report for this?

Have it. Submodules made fun, Locale was missing. Pulling everything from scratch solved the issue.

I don't really understand, why this is showstopper. Why can't you click on that next button on the splashscreen?

I don't really understand, why this is showstopper. Why can't you click on that next button on the splashscreen?

2.79 does not have such problem, but since workaround is quite simple, I would not consider this to be a bug

Ok my mistake, I think what I did was open new file instead of restarting Blender.

Here the bug:

I will make a video. Give me a few moments please.

In T69002#866391, @Reiner Prokein (tiles) wrote:

Yes, that's still an issue. Nobody has fixed this one yet. I have tested it before a few moments with the newest 2.83 buildbot build . There's the above told workaround available for the users. But at the moment nobody can make a working startup.blend file to compile new defaults with a two rows toolbar for example. Or another tool shelf default button than Box Select.

To reproduce:
Remove all stored information in the appdata path. We need a blank Blender.
Open Blender. Do NOT click at the Next button in the splash screen.
Resize toolbar to two rows.
Save startup.blend.
When you reopen Blender, then the toolbar is single column again.

Hm, this bug seems not only to block any new factory defaults in the tool shelf, but also in other UI areas. I saved a startup.blend with a different stretching method in the UV Editor. And compiled with it. And the factory default stretching method is back at Blender defaults then.

Forgot to say, the other way to reproduce is to create a two column tool shelf layout, save the startup.blend, and compile with this startup.blend then. With a fresh installation you will have it single row again then.

Yes, that's still an issue. Nobody has fixed this one yet. I have tested it before a few moments with the newest 2.83 buildbot build . There's the above told workaround available for the users. But at the moment nobody can make a working startup.blend file to compile new defaults with a two rows toolbar for example. Or another tool shelf default button than Box Select.

I have re-triaged this report and can not reproduce it.
Can you please check if this is still an issue in latest build?
https://builder.blender.org/download/

Like Brecht said we don't write global area data to files yet. There is code for it that used to work fine, but we disabled it for master as there was still too much in progress work going on.

Looks like there's already a pre-existing revision that adds this same functionality but enhanced. Closing.

Small update what windows does, if you rename a file from "myimage.png" to "Myimage.png" in a different folder.
If you copy the renamed version then to a folder where a version exists that is named in the orgin spelling "myimage.png", the following happens:
Windows realise there is already a filename with same name, and ask to overwrite it.

Closing then.
It's not worth creating an internal workaround that messes up the code to solve this.

I honestly don't think it can be a "to do".

In T71772#819627, @Harley Acheson (harley) wrote:

You can right-click on any file name and select "Rename" from the context menu.

How do you rename a file by the blender file browser?

How do you rename a file by the blender file browser?

OK. Nevertheless this should be fixed.
For the user it is not really understandable, why Blender can't rename a single Letter in a filename, but all other apps can do it.

Yes, renaming does work correctly from Windows Explorer directly; probably they do work around the issue with the filesystem directly which is easier as an OS. Renaming 2 files to "test" and "Test" is an example I gave as a way to expose the underlying issue.

In T71772#815328, @Steff Kempink (mswf) wrote:

The renaming between File and file is working in explorer I see. But an application asking Windows to rename File to file still won't work.
You can see that Windows doesn't see the difference between 'test' and 'Test' in this screenshot, where I already have a file 'test', then when I rename another file to 'Test' (with a capital), Windows throws this up:

The cause is described here too:
https://en.wikipedia.org/wiki/Filename#Letter_case_preservation

The renaming between File and file is working in explorer I see. But an application asking Windows to rename File to file still won't work.
You can see that Windows doesn't see the difference between 'test' and 'Test' in this screenshot, where I already have a file 'test', then when I rename another file to 'Test' (with a capital), Windows throws this up:

Thank you for the answer.

This is a core issue with Windows. It cannot tell the difference between a path with different capitalization. This is a problem that boggles the mind of everybody who develops with Windows. You can see it if you try to make a "File.txt" and "file.txt" next to each other: Windows will not allow it because it will tell you a file under that same name already exists.