Based on the rejected bug report here:
https://developer.blender.org/T67502
This is getting extremely confusing. Even the most obvious bugs are getting completely arbitrarily closed as supposed feature request, just so that they can be directed to channels where they can be safely ignored 
Thatās because itās not a bug. Blender currently doesnāt know about the earlier window you closed, and every time you open Preferences, it has a fixed size.
Hereās a thing. Recently, Iāve reported also for example: https://developer.blender.org/T67242 this one, which has been confirmed and assigned medium priority.
If I had to bet which one will be considered a bug, and which one a feature request, the common sense would be to switch it the other way around. Imagine seeing a āNew Featuresā changelog:
Which one of these two in the New Features list does sound like a new, added functionality, and which one sounds more like a bugfix. I know, right?
If you create a new window in Blender by going to Window>New Window, then once saved, that Window remembers both size and position. So the code for saving window position is already there. Not only that, but also, the open state of User Preferences window is saved with the .blend file! So if you open user preferences via Edit>Preferences, and save the file, if you load the file, itās still open.
Hereās a thing. If you create a new window through Window>New Window, adjust the new window layout is it has just one editor, and set that one editor to be user Preferences, then you get pretty much exact same thing, except with remembering window position and size. All it takes here is changing Edit>Preferences operator to open same type of window as Window>New Window. On top of that, it would allow for deprecation and removal of this special window type used for user preferences, which apparently uses different code for window display.
But back to the original point. I am no longer able to tell what could possibly be considered a bug, and what would not. Itās just so arbitrary, with no clear rules behind it, that I really donāt know what I should report and what not. If window remembering its size is a feature, but addition of support for texture transform node in workbench is a bugā¦ I am lost hereā¦
This is not true, if you click on Window>New Window it will always open it with the default size and position, same behavior as for the User Preferences.
If you save the file with some open windows they remains of the same size at reopen, but that is also true for the User Preferences.
As for the other one, I think that the ratio for considering it a bug and not a feautre request is that the old 2.7 viewport did show the effect of the texture mapping in āMaterial modeā, so it makes sense to be able to see it without being forced to use Eevee (Iām just guessing here).
Yes, but if you open it once, and save the file with it, once you reopen that file, the window will stay the same size. My point is if the code to remember window size is already there, why not use it?
I get it, but it may be a bit more complex then it seems, you need to store those infos in the blend file at save time (and this alone itās probably something that devs would want to discuss before).
You also need to keep them always around, since you want to be able to open the windows with those sizes at any time, so I think this makes it different from reopening a windows from a saved file, in which you only read it at startup.
Still guessing stuff here 
, but I just wanted to point out that things that seems obvious from the user point of view might not be that easy, or immediate to implement.
Everything can be improved and fixed of course, but it is slightly more complex a problem that it might seem at first.
An important thing to know is that we donāt actually have a separate āPreferencesā window at all. We have exactly one ātempā window that we reuse for different purposes. You can easily get a sense of this: render a still to the ārender windowā then move that window somewhere else, like to a different monitor, then open Preferences and see that it replaces the render window at exactly the same place.
So we canāt have a popup File Manager at the same time as Properties or a Render window. This issue goes a bit deeperā¦
To overcome this, I created a new Workspace āSystemā and one of the viewports in there is the preferences, e.g.
In a post on Developer Blender Pan Beeb posted a small piece of code. What it does is set render window mode new window opens this window using some settings and switches to Preferences. After testing this works perfectly. Though his approach did not store the prior settings to the render size. So i stored those. I made a simple addon for it and works like a charm
This video was prior before i added height also being able to be adjusted
For those interested, you can find it here. I added width and height. The panel is a different vs the normal one, we dont see the hamburger menu in the bottom left. You can still save it from the āPreferencesā button you see at the bottom
While itās cool, this is definitely not something that should be an addon
True, but do you have a better solution?
Since i see the requests made 2-3 ago, perhaps even longer and no adjustment being made. For the time being this is nice.
I did something similar with posting bugs. Currently, we have this automated method, i actually made that myself before they introduced about the same thing. I was done trying to find the data and do repetitive steps, adding the system specs in the bug post. I made simple addon which copied the current has tag so a user could only needed to paste it. At the time that was the most important thing, finding or memorizing that tag was just a paint. I posted it on RIghtClickSelect and some time later a much better method showed. I was quite baffled such a simple thing wasnt implemented earlier/ I guess lots of peeps didnt report anything just because of this hastle.
Here you can see the much better improved version
It should not not be an addon like you said, but for the time being it does solve an āissueā for some people and i therefor i hope it helps. Perhaps some dev catches it and thinks āhey this is usefullā. Thats how this community seems to work right
Yeah this drives me insaneā¦ that the Prefs window always moves/resizes. I can understand whyā¦ at least the position, but the scale drives me nuts.
I will try that addon or maybe make a workspace as someone says, for nowā¦
It is actually perplexing that we should even ask for this function, Iām a vet VFX artist and been trying to learn blender for personal projects and this is incredibly frustrating. Iāve been working for a few hours setting up a project for a bunch of characters and Iām ready to go back to Maya.
Blender gives people many reasons to rage-quit by missing the most essential functionality at many places, but to be honest, user preferences window not remembering the size is probably at the very bottom of that list 
There are way bigger issues than this, so if the annoyance of this scale is what makes you go back to Maya, then you should not even bother trying any further, because eventually youāll find much bigger obstacles 
If the developers, instead of adding something that decides the fate of the program, cannot add a specific thing (which I have not even thought about in 6 years), and there are less than 10 people in the topic of its discussion, then this looks normal. Although I obviously cannot speak on behalf of the developers, you will agree that when there are so few people in development, it is not surprising that such a strict expenditure of human resources. Especially considering that we are talking about a function that requires reworking the entire blender. You can always contribute (both in the C part of the kernel code, and through python, as in the example above)
But again, I cannot judge the importance of this function, who knows, maybe someone will overestimate its priority ā¦
