I doubt, that there is a lot of software on your computer, that is free of bugs …
I don’t think there are any unreasonable messages in this thread, and I’ll leave it exactly as it is.
@ArthurNeeman, please don’t misunderstand me: it is not the case that we think these kinds of small bugs are unimportant. On the contrary, we take the quality of the software very seriously, and we try to fix bugs as soon as possible after they are discovered, either by our internal testing team (the best case), our beta testers (the next best case), or by a paying customer (in the worst case). However, it is not always practical to fix even small bugs right away, and even if a bug is fixed internally, it is not always practical to release that fix in a minor update to the existing version.
For example, we are now several months in to the development of the next major version of Dorico, and there has been quite a lot of refactoring of existing code. This may often mean that the shape of a particular bit of code has changed quite a lot, making it more complex to apply fixes made on the current development builds to the older, stable release branches. In the worst case, this means that the bug needs to be fixed twice.
For a serious bug, we would certainly consider that approach (and have indeed done so in the past), but for a minor bug that affects only the state of a user interface element under some circumstances, it is difficult to give that sufficient priority to take up development and testing time – not to mention the time of the other teams in the company who are involved in each release, however small – unless it is convenient to roll that fix into another update that is already planned.
As it happens, we will be releasing another very minor “hot fix” for Dorico 3.5 after the holidays, which will include a couple of fixes in addition to its primary purpose, which is establishing compatibility with the Rosetta translation layer on the new Apple Silicon Macs. That build is already complete and going through testing at the moment, and we are unlikely to backport any further fixes to be included in that build. If, however, we have cause to go back to the start of the testing process with that build, I’ll look into whether we can backport this specific fix.
Each product team at Steinberg is to some degree free to determine its own release strategy and engineering methodology, and we in the Dorico team have not historically set things up such that we expect to go back and release updates for the previous version after the release of the next major version, though we know that is the established practice of the Cubase team. I don’t rule this out altogether, though I do note that we are a much smaller team within Steinberg than the team that is working on the features and technology for the sequencer products, so we cannot take on this additional burden without giving it some serious consideration.
I believe we have demonstrated a strong commitment to quality and to supporting our users. I hope that I have explained adequately the approach we take to implementing features and fixes that you understand a little better where I am coming from.
16 Likes
Thank you for this explanation. My heart is calm now.
Think of this as a necessary talk (included in the price).
@ArthurNeeman
Here comes my humble suggestion: If you post a bug report, please also consider tagging it as an issue.
(Looks like there isn’ a bug-tag available right now.)
(If it is too late for you to edit-and-tag it, then just do it for your further issue threads.)
This helps people manage new threads posted in this discourse forum.
Maybe there is at least some designation a person could obtain on the forum as “Quality sleuth” or “Bug honcho”. Or maybe offer naming rights to the bug fix. 
Our experience with the Dorico development team, and dspreadbury in particular, has been excellent in 2020: We reported several issues, some of which were bugs, others were missing functionalities, and we got answers, most of which quite helpful, and some saying: “you’ll have to wait until the next release”. Which actually did happen.
We quite understand the challenge of prioritizing the vast amount of user requests related to bugs, but mostly to enhanced functionalities, and choosing ways to implement sometimes conflicting functional requirements from users.
Were we 100% happy? No. Do we think the Dorico team did well? Sure! Can they do better? Yes, but if you got already 9,5/10, it’s not easy .
So, we wish the Dorico team an excellent 2021, and thank them for their accomplishments of 2020!
5 Likes
I totally agree with you!
Happy 2021 to all!
So tell me how do you know which instrument is active when you switch to Play mode from Engrave or Print modes.
You don’t.
On the other hand, if you know what you want to hear, you can double-click on each VST Instrument to ensure that it’s turned off, then turn on specifically the VST Instruments that you do want to hear.
On the rare occasion that I need to switch something off, I’ll mute that track in the mixer. I’m rarely aware of which instrument is assigned to which VST instrument, let alone which slot, but maybe I’m in the minority here?
You click on the one your want. 
There’s a bit more to it than that, @Derrek
Let’s say you’ve got four instances of HALion Sonic SE. You have them all turned on. Switch to Engrave mode. Switch back to Play mode. They all appear to be turned off, yet in actuality they’re all turned on.
If you now click on one of them to turn it on, they’ll all still be turned on.
There’s clearly a bug here, but it’s certainly not one I’ve ever spotted, as it’s never occurred to me to turn a VST Instrument off in Dorico.