Without seeing anything else, I'm going to go out on a limb that the Preferences dialog also looks weird and you probably are using an older Intel integrated GPU. If that is the case, I would evaluate CurrentValue[$FrontEnd, {RenderingOptions, "PreferredGPU"}] = "Software" and restart the app.

Great. If you use 3D graphics a lot, you might want to consider setting 3DRenderingEngine to OpenGL while PreferredGPU is set to Software.

Resetting Mathematica on A solved this problem. Input auto replacements now works.

Hi Stefan ! this is precisely what we end users are requesting with every minor or major release. If the same developers who have created old functions are busy creating new and new functionality then not much time or resources can be invested to fix the old issues. Additionally, new bugs are incorporated along the way either because the new features rely on older functionality/infrastructure under the hood or possibly because new bugs are inevitably incorporated while developing newer functions. What would be considerably better is to put a great deal of effort to get either 12.3 or possibly 13.0 free of critical bugs and old lingering issues in the system. Thanks !

The fact that 12.1.1 was an official bug-fix release and 12.2 was not in no way implies that bugs were not fixed for 12.2. On my own part, I had no bug fixes go into 12.1.1 and several dozen go into 12.2. On a related note, I also did sweeps through some categories of open bug reports. I found that over time more than 30% of the bugs from Integrate were apparently fixed. This can happen due to continued code overhaul wherein "collateral damage repair" occurs (one bug fix actually fixing more than one problem, with the developer unaware of this).

As it happens, I would also like to see more effort put into fixing open issues. I am simply trying to point out that the ongoing efforts in that direction are appreciably greater than what is being claimed in this thread. I will also state, as others have done, that this cannot happen at the expense of all new development, as that would sacrifice the future for the present.

I fail to see how the quoted remark in any way indicates a failure to check for bugs and prioritize fixing them. First, it referred rather specifically to one function, Integrate. As it happens, this one does not lend itself to easy fixes, and its peculiar features in no way extrapolate to other areas such as graphs and networks or machine learning. Whatever you might want to think about prioritizing work on this one (admittedly important) function, forget about it. The knowledge for how to do this simply does not exist. Some of it will come into existence, and some will in fact be invented by my Wolfram colleagues. But it is a process, and not a fast one. On the brighter side, it has begun-- there is a project in early stages to overhaul some of that functionality.

I have no particular dispute with your second paragraph, or indeed with much of the first one. These involve matters of prioritization and I neither speak for my employer nor in all cases agree with the choices that emerge. (I will state that they are reasonable choices given the competing factors both commercial and otherwise.) But the first part of your first paragraph made a leap from handling of very specific functionality to our entire quality assurance efforts, and that leap is simply unfounded.

One final remark is that we do offer enterprise support. While I have not had much involvement, my limited intersection with that sphere of the business leads me to believe the problems encountered by that set of customers do get high prioritization. Often enough it is not (entirely) because they pay more, but because they put stress on the software in ways we rarely see, and thus uncover issues that otherwise might be missed. And of course these will be important to other enterprise customers. What we fail to do is offer bug prioritization or fix roadmaps to all on a bug-by-bug basis. Should we do this? That question is way above my pay grade.

I agree bugs that affect multiple users, especially ones doing serious R&D or related work, should get priority. I cannot comment specifically on FindMaximumFlow because I am unfamiliar with that area of the code base. Possibly it is simply difficult to fix?

As for general factors that go into prioritization, I will disagree on the "bug is a bug" point. Some are simply more important than others. As for weighing in enterprise customer needs, I see no reason why business considerations should not be taken into account. But again, those also get balanced against questions like "Is this really a bug vs feature?" or "Is there a simple workaround?" or "Is this user error?" Enterprise customers do not get a free pass on these, any more than others.

Please file a report to support@wolfram.com. They usually monitor the community, but not always.

Documentation can be updated in paclet updates, which are (mostly) silent, but they need to know about the problem.

Here is another example in the Documentation which used to work in 12.1.1 but not anymore in 12.2:

GeoSmoothHistogram[
WeightedData[
CountryData["UnitedStates", 
"LargestCities"], #["Population"] &], 20, PlotLegends -> Automatic]