Some call it posturing and some call it an outright and baldfaced lie. As a small account I am not expecting so much as a phone call, let alone a face to face. That said our reaction is not in any way a "kneejerk", Broadcom is part of the problem to be sure, but the broader issues we have faces with VMware are a deepening of problems that were already there.
Let give you some excerpts of a recent (in the last month) interaction I had with VMware. For needed context we had hit a bug in the patching train a while back when we were on 6.7 I think, that hosed vcenter so badly I just nuked the old VM. I installed a clean copy under 7 because rolling the failed patch looked like it was going to be a PITA. I checked into the old VM a little deeper, and the failure was do to a long running known issue were a previous patch had turned on root password expiration, and the patch lacked validation that accounts needed to install the patch were working before the patch fired off.
My current experience is that about three patches into the 7 series the same thing happened, so I contacted support. After me telling them in detail in my initial bug report about the problem, it's cause, and the KB article number for the root password issue, they literally told me "I'm afraid I will need to direct you to the vSphere feature-request page" and told me to roll it back from a back-up. It took them hours past the the reply window to contact me, and when they did the support agent's only instructions were to roll back the bad patch or rebuild it from scratch again. I literally cloned the VM and rolled system back within a hour of the bug report being sent. That report detailed specific issues (root password exp, lack of test in patch for exp account, GUI for vcenter cant reset password once it has failed). I asked for acknowledgement of these bugs, which are documented in VMware's own KB articles, and issue or tracking numbers for them.
The agent then went back to talking about restoring a backup from before the failed update instead of addressing the multiple underlying issues that caused it. The issue being that VMware has gotten so sloppy with it's QC that it has issued a whole series of updates that won't safely install from the GUI. That these failed patches can't be rolled back from the GUI once they are stuck, and all further operations in the management section are blocked. These errors have been known to the company for some time, and are even documented in KB articles that go so far as to instruct people NOT to use the UI and apply all the patches via command line via .iso files. These instructions weren't sent out to operators, no warning was. Instead, we were left to either find the trail of bread crumbs on our own, or waste hours with our infrastructure in a failed state.
I can't rely on a system from a company who's product prompts it's admin's to update it using a method that the company itself recommends you not to use. I can't trust a company that knows that a problem exists that could catastrophically impact their customers and can't be bothered to proactively notify them. I also can't stomach that a full major release version later, that VMware can't add a simple one line script test to check if the root account was expired. (in truth they DID put it some of them, just not ALL of them, there is a screenshot of the GUI warning about the expired password in one of the KB articles)
The reason this is still happening is that VMware has become deeply dysfunctional. Broadcom has bought CA and Symantec. They seem to have quite the nose for buying companies that are trading on their names alone. That Symantec is just as deeply dysfunctional as ever is just another warning sign that VMware is about to get even worse, not better. The only consistent performance is under performance right?
So I already had to have the hard hall conversation with my boss, and we are probably porting off VMware in the next two months. We had been in discussions about moving ON to vSAN back on 6.7, but we deferred do to covid belt tightening and concerns about the patching issues. A year on those problems are worse, not better. We already pay for the windows licenses to use HyperV. We paid for VMware (since what, the 3 series?) because of the value add and the maturity of the esxi hypervisor. The company squandered it's 10 year engineering lead. If I have to apply every patch via the command line, I might as well move to the platform I already paid for, which is less picky about hardware, less driver problems, and a GUI that I hate but at least dosen't break with every browser update.
HyperV won't make my patching heartburn go away, but it's the same patches, process and tools I have to use for the VM's and bare metal anyway. Which is to say, while I'm annoyed, this move isn't an emotional decision. It's a coldly rational one, based on business requirements for reliability and uptime that VMware has proven it can't support.
Sounds like you already have your hand on the ripcord, but I wouldn't hang on too long if you are cashing out options going into the merger. Best of luck, I know that there are still plenty of good people there, but those of you on the inside will have to decide if you can hold the roof up by yourselves.