the most obvious bug problem i had was with localisation (i've heard this is fixed but not updated yet) where it constantly returned en-US. this is pretty embarassing imo... it shouldn't be possible to ship in this state and when someone raises the issue - imo you fix your build process so it can't happen again. that might be a big ask but its not unreasonable imo...

i had some real issues with the physics not being deterministic or handling the most common edge cases like high speed objects with thin colliders. i'm inclined not to blame PhysX... tbh part of this is poor game design on our part that it was a problem. we should know better than to want to rely on deterministic physics...

i don't think they have particularly implemented components well. but that can be personal taste - everything having a transform is reasonable but the implementation of transform itself i find terrifying and confusing. it seems to really be an elaborate tree thing containing the whole hierarchy...

if i want to iterate over all of the components of a given type i have to use some scary looking functions with 'find' in their name which suggest to me not really understanding the implementation benefits of components...

scales live in the matrices...

the maths library is missing lots of common things and is messy (eg. vector3.lerp vs. mathf.lerp) some of this is because c# makes performant syntactic sugar hard with its lack of clean non-temporary references (you can use boxing but it is, in theory at least, slow)

the random number generator is not very good - maybe its a mersenne twister or something suitably complex but the results are easily beaten with the usual LCGs (which have their own classic problems).

the game object interface is not very complete. where are get and set position? i apply them to the transform? does it cache this? in short my confidence is broken when something like moving an object is handled poorly - its a classic case of something you often want to cache until the next frame and imo that should be a clear part of the entity/game object system not something you have to investigate or write yourself. i find myself writing functions to get lists of children - finding that including self as a child is vague and ambiguous in the built in functions and so make aliases for them so i don't have to get confused by that... find parents and children requires going through the transform? that is - to me - severely broken encapsulation. forget the class keyword - the spirit of OO is worth following imo (if not the die hard 'everything is an object' approach).

the overheads of .net are there but they do not cause me a problem afaik.

all my problems can be summed up as 'i don't like writing this code i always have to write for any game - why isn't it in your engine already? i would have put it there.'

the editor is really good i can't say that enough. its a small sentence but the implications are enormous... its what makes unity so good for making things quickly.

really as an argument that is super significant... making tools regardless of how is enormously time consuming compared to working around the issues i describe.

i've worked at 'AAA' studios - some of them are pretty appalling too. lots of programmer wankfest code for 'performance' which is completely unjustified if you go and measure it... tbh i'm embarassed with the state of gamedevs. i stayed out of the industry for a long time (my fault) assuming i wasn't good enough - when i finally got in the most overwhelming lesson was that the quality bar is much lower than i could have imagined... even in the engine, rendering, audio etc. specialist areas...