If you believe that then you have neither used or unsterstood the concept of the new scriptable render pipelines. Nevermind the fact that most people already switched over to either URP or HDRP.

What is your source on that? You do not have to be a publicly traded company to get source code Access, the source code is actually pretty well written and maintained. With the new approach of features being delivered in packages you get all the source directly in c#.

Unless things have changed drastically since I was at BigCo (and maintained a branch of Unity 4 for several teams, so was very familiar with the codebase, and their native code was horrific) unless you have serious sway you don't get engine source, and in my experience that's where a ton of the bugs that will screw you lie. In fact I'm dealing with a few right now at a smallCo that definitely doesn't have access (we've asked) to the important pieces of code that are making our lives hell.

I definitely agree that shipping more stuff in C# packages is a good thing, and those are mostly well written, I mostly just hate the actual C++ engine, which is frankly a disaster held together by bubble gum and spit.

If you are on Mac you can use CTRL+CMD+Space to open the symbol picker that also allows searching for symbols. There is something similar on Windows iirc.

The shortcut on Windows is WIN+PERIOD. You can continue typing and it will search for matching emoji. For example, type WIN+PERIOD+smile+ENTER and it inserts a smiley face. It also supports mathematical symbols and greek letters using the mouse, but the search doesn't find them. A shame, because it's nearly useful.

Very interesting release. The autorelease is especially noteworthy... also I worry how hard it would be to have more finegrained control over allocations, releasing the memory instantly is not always the most perfomant way. In games for example big (temporary) allocations are often performed in some kind of arena buffer that gets cleared at the end of a frame (NativeArray in Unity does this) and thereby circumvents alot of unnecessary deallocating. How feasible would it be to implement such an allocator in V without losing the autorelease for the other cases?

You are right, and V will give the developers that control.

It'll be possible to use `[noautofree]` in modules and use manual memory management with or without arena allocation.

Arena allocation should also work with -autofree, I don't see why not, it's just malloc() and free().