We run on high quality, and likely over provisioned, hardware. Under SPLA we have SA and ready access to upgrades and patches. The ST underpinnings are very solid for us and, like you, the IMAP and to a lesser extent POP could be described as nothing less than Rock Solid in our experience. There have been severe calendar wrinkles and things like that predating MAPI. The more advanced protocols have been a challenge and I think you can see from historical Tim and employee posts that ST didn't really embrace Outlook functionality as a priority. MAPI has certainly introduced some new challenges. Having waded in as deep as they have there is only one profitable way out for ST and that is to be a real alternative. It sure looks to me like they are plying serious resources to getting there and that they are now open to and better understanding that Outlook support is critical.
Perhaps this should be a new thread but I'll stick my neck in the noose here (reluctantly because this thread is so public and well beyond licensed users). MAPI has posed some challenges to be sure and I think it would naïve to expect that some of them wouldn't perk up to the sizzle level and become apparent to users. I accept that and over the years we have put many unpaid hours into being proactive and minimizing or eliminating the impact when things do slip through. It will be no different with MAPI other than the added complexity and wider scope of the things that may be impacted.
We are paying for the MAPI licensing essentially to continue to support one or two key users in a domain of hundreds that are using MAC and need EWS which is now bundled with MAPI. Although we have done some minor rollouts we have not encouraged or even made most of the users aware of the MAPI option. The few that are active are accounts using a recent version of Outlook that used auto-discover or a few where we are the MSP and have significant ability to monitor and be proactive. It works for us in part because we've been very cautious about upgrades and looked before we took the leaped. We are several months back in releases and what that version supports works pretty well.
What would be very useful for us would be an approach that other developers we work with take. Once something is through beta it is released as the leading edge product with the most up to date features. After some time, typically a few weeks, and following a few inevitable bug fixes and tweaks, it becomes the stable full release product, without any additional features having been added and the cycle begins with the next release, including new features, being the leading edge product.
With each of these SM releases there are fixes to the inevitable things that slipped though but there are also new things added that have introduced the need for more fixes. What we really need is for something like 8025 to have spawned a track that fixed any of the issues within it to become the stable mainstream release without adding/risking new functionality so that we could safely upgrade. Then the new advancements would go though beta and get released into the leading edge track which would run parallel to ongoing feature additions in the next candidate leading edge release. When the leading edge track meets the stable criteria it once again become the stable release track and the track into which the new feature were being added becomes the next leading edge track.
The current approach is extremely risky from our perspective. Each time it looks like we have something we can safely move forward with, something significant emerges with additional features that have been added. I think it is causing many of us to hold back on MAPI.
To be fair to ST there are so many wrinkles in Outlook and the documentation for the protocols that many of the problems are not of their making. I think that is all the more reason to move forward with stable and leading edge releases. Not all of what has gone wrong would have been foreseeable in the beta testing, it needs to be exposed to a larger base of use cases and that is what the leading edge track and the commitment of resources behind it to react quickly is all about.
Finally, posting of these "horror stories" as many would interpret the calendar issues (which we've seen pre MAPI) to be, for all to see, introduces another problem. If you have clients with an IT department rather than your organization being the MSP, and if that IT department is reading though these threads, they are likely contractually and ethically bound to act in the employers best interest and take them into consideration. Under many contracts, failure to draw the discussion to the attention of management or to investigate moving the organization to another platform would be grounds for dismissal or exiting the contract. I know with certainty that I am not the only one to have held back posting an observation that might have been useful because of this. Again, using other developers we work with as an example, these types of threads are often limited to licensed users or even, in some case, invited participants from among licensed users although that wouldn;t be my preference.