Before showing us what comes next, perhaps we should talk about what we already bought

For quite a long time, I have tried to give Microsoft Flight Simulator 2024 the benefit of the doubt. The launch was bad; at this point, I find it difficult to describe it any other way. There were simply too many problems with stability, performance, navigation, controls, Career Mode, content loading and VR to dismiss it as merely a difficult launch.

Even so, I thought it was a matter of time. This is an enormous and technically ambitious simulator, and a platform of this scale inevitably needs work after release. So I waited for the first updates, then the next ones, later SU5, and now SU6. But there comes a point when looking at the calendar necessarily changes the conversation: MSFS 2024 launched in November 2024, and we are now at the end of August 2026. Almost two years later, we are still talking about stability, performance, navigation, Career, controls, VR, CTDs and regressions introduced by certain updates.

And perhaps even that language is too mild, because some of the problems still being discussed are not minor inconveniences or small defects waiting to be polished. For some users, certain parts of MSFS 2024 are currently unusable.

I am not using that word for dramatic effect. There are users who, after an update, have gone from a perfectly usable experience to performance that makes flying in VR effectively impossible. Others encounter reproducible CTDs with particular combinations of graphics settings or runtimes, while some cannot reliably start flights or find parts of Career so affected by freezes, performance problems or erratic behaviour that they effectively cannot use them normally.

This does not happen to everyone, of course. Other users with apparently similar configurations report that SU6 works correctly, or even better than previous versions. But that does not make the problem disappear. If anything, it highlights another issue that I find particularly important: almost two years after release, the experience still depends far too much on a combination of hardware, configuration, game mode and circumstances that users often cannot predict.

That is why I think simply talking about “bugs that still need fixing” can end up understating the situation. A bug is an anomaly within a product that, broadly speaking, fulfils its function. When an update takes a user from being able to fly to being unable to do so, when VR becomes impractical, or when an entire mode can no longer be used reliably, then for that user the product they bought has stopped fulfilling its basic purpose. That reality should carry considerably more weight when we discuss the state of MSFS 2024.

SU6 fixes many things, and that is positive, but it is also revealing. The fact that a Sim Update still needs, almost two years after release, an extensive list of fixes in fundamental areas does not merely demonstrate that the team is continuing to work on the simulator. It also shows how much remains to be stabilised in a product that was not sold as Early Access, but as a finished release.

In Career, for example, mechanisms have had to be introduced to avoid penalising players when the simulator itself detects that certain failures are not their fault. That is a welcome improvement, but it is also a striking indication of the extent to which the software needs to distinguish between a player’s mistake and a failure of the system itself. In VR, reports continue concerning performance, stability, DLSS and different runtime configurations, while navigation, stability and resource-management issues still appear and force part of the community to check after each update not only what has been fixed, but also what may have stopped working.

Not every one of these problems affects every user, and I am not suggesting that they do. But I also do not think “it works for me” is an adequate response when other customers cannot properly use significant parts of the same product. The relevant question is not whether somebody can run it successfully, but how many users need to be affected before an issue stops being merely a “known issue” and becomes a critical product priority.

When the customer becomes part of the development process

I also think we have normalised something else far too much: buying complex software now seems to mean participating in its maturation process for months or even years. We install betas, clear caches, change settings, reproduce bugs, submit reports, try different runtimes, change drivers and return after every update to see whether whatever prevented us from enjoying the simulator has finally been fixed. When it has not, we simply wait for the next one.

I have no problem with a community wanting to help improve the simulator. I follow the updates myself precisely because I want MSFS 2024 to succeed. But there is a considerable difference between helping to maintain and improve a product and having customers participate in a development, diagnostic and stabilisation phase that reasonably should have taken place before the product was sold as finished.

Betas can be extraordinarily useful, but the problem begins when the customer starts to feel that the commercial product itself is effectively operating as a permanent beta. When that feeling persists for almost two years, I think it is legitimate to ask where exactly the line lies between maintaining a simulator and finishing its development after it has already been sold.

Gamescom: the showcase and the reality

This is why Gamescom left me particularly uncomfortable.

Microsoft Flight Simulator went there to present new content, new activities, new aircraft and new updates. I have nothing against that. Gamescom is a commercial event, and I fully understand why Microsoft wants to showcase the best possible version of its product. What I find much harder to accept is that, after a launch like MSFS 2024’s and almost two years of fixes, the public conversation can remain focused primarily on what comes next while the state of what has already been sold is largely relegated to patch notes, forum threads and lists of known issues.

Before putting MSFS 2024 back under the spotlight to show us what is coming next, perhaps this would have been a good opportunity to speak openly about what has already happened. Not with another carefully worded statement about how hard the team is working, or another generic assurance that the community is being heard, but by doing something considerably more difficult: publicly acknowledging that MSFS 2024 launched in a state that fell short of what customers should reasonably expect from a product sold as finished, and explaining what went wrong, what was learned and which problems are still considered fundamental.

That, too, is part of presenting a product.

At a trade show, it is entirely reasonable to use systems prepared to demonstrate MSFS 2024 under the best possible conditions. Nobody expects Microsoft to deliberately configure a simulator badly in order to demonstrate its own crashes. But that is precisely why there is a distinction worth remembering: outside those carefully prepared demonstration systems is the version installed on users’ machines — the one that can suffer CTDs, lose acceptable VR performance, experience regressions after an update, encounter navigation problems or unexpected behaviour in Career and, for some customers, simply fail to operate reliably enough to be used normally.

Both are Microsoft Flight Simulator 2024, but one appears under the spotlights while the other tends to remain in the forums.

I think both should be part of the same conversation, and that is precisely why I missed hearing some uncomfortable questions at Gamescom.

I would have liked to hear a clear explanation of what went wrong in November 2024 and why, almost two years later, major updates are still required to correct fundamental parts of the experience. It would also have been reasonable to ask which problems Microsoft considers genuinely structural, which it now considers acceptable, and what metrics it uses to determine whether MSFS 2024 is actually improving: CTD rates, affected users, performance, unresolved issues, Career mission completion rates, or some other measure that tells us more than the length of each Sim Update’s patch notes.

Another important question would be when Microsoft believes MSFS 2024 will cease to be in a stabilisation phase and can genuinely be considered a mature platform — or even whether there is a clear internal definition of that point. I also think it is legitimate to ask who took responsibility for deciding that the product was ready to launch in November 2024, whether a serious post-mortem of that launch was conducted, and whether its conclusions changed anything about quality assurance, testing or the criteria used to decide when a build is ready to reach customers.

But there is one question that I find particularly difficult to avoid:

If MSFS 2024 had not yet been on sale in November 2024, would Microsoft have considered it acceptable to release it in exactly the state in which it launched?

Either answer raises a problem. If the answer is no, then it would be reasonable to ask why releasing it became acceptable once a commercial date had been committed to. And if the answer is yes, then perhaps the problem runs even deeper, because it would mean that its condition at launch genuinely met the internal quality standards considered sufficient for selling a finished product.

I would also ask something more immediate:

If a customer buys MSFS 2024 today and discovers that VR does not work properly on their configuration, that Career has problems preventing them from playing normally, or that they cannot reliably start flights, does Microsoft consider that customer to have received the finished product they paid for?

I do not think that is an unfair question.

Responsibility also means priorities

There is another issue that is difficult to ignore while new content continues to be announced.

I am not suggesting that all development of new aircraft, activities, cities or features should stop until the last bug has disappeared. That would be unrealistic and probably would not make sense. But I do think Microsoft should explain much more clearly what priority fundamental problems have compared with the continued development of new content.

The familiar answer that “different teams work on different things” may be organisationally true, but it does not resolve the underlying question. Teams have sizes, budgets, objectives and priorities, and deciding how many resources are devoted to stabilisation, quality assurance, new functionality or content is itself a product decision.

So when there are customers for whom fundamental parts of the simulator remain unusable while the showcase continues to fill with new features and content, the question inevitably arises:

What is actually considered most urgent within the project?

Taking responsibility does not mean cancelling new content or appearing in public every few weeks to apologise. It means being able to explain clearly what went wrong, what caused it, which problems remain unresolved, what the current priorities are and what criteria will be used to determine whether those problems have genuinely been solved.

That would have done far more to restore my confidence in MSFS 2024 than any announcement at Gamescom. Yet that conversation was not on the stage, nor did I hear those questions being asked. Perhaps that is why every new announcement interests me a little less — not because I do not want new aircraft, new cities or new activities, but because before being shown what comes next, I would like to regain confidence in what I have already bought.

And after launch, what changes?

There is one final issue that I find increasingly difficult to ignore: incentives.

Microsoft has already launched the product. It has already been sold. The ecosystem continues to operate and new content continues to arrive. None of that proves that Microsoft or Asobo do not care about the state of the simulator. I cannot know that, and I am not going to attribute motives that I cannot demonstrate.

But one objective circumstance has changed: before launch, having a sufficiently finished product was a prerequisite for selling it. After launch, the customer has already paid.

That raises an uncomfortable but, I think, legitimate question:

What real pressure exists to resolve structural problems quickly once the product is already on the market and its ecosystem continues to operate and generate revenue?

I do not know the answer. As a customer, all I can do is look at the result, and the result is that, almost two years later, we are still waiting for certain updates to make stable, consistent and predictable something that was sold to us as finished, while for some users parts of the product still do not even reach that minimum standard: they simply cannot use them reliably.

I am becoming less interested in promises, roadmaps and long lists of fixes. Nor do I need to be told once again that the team is committed. What I need to see is something far less spectacular: several consecutive versions in which the simulator works reliably, fixing one problem does not introduce another equally significant one, and installing an update no longer feels like beginning another round of testing.

I want to be able to launch the simulator, enter VR, choose a flight and fly without first wondering what might have stopped working this time. Almost two years after release, I do not think that should be a particularly ambitious expectation.

When that happens consistently across several consecutive versions, I will start to believe that MSFS 2024 has finally reached the point it should have reached much earlier.

Until then, I find it increasingly difficult to trust it.

Now if we would only receive such a well reasoned and detailed response. Sadly, experience suggests that we will not.

Personally, I’m not as interested in hearing what went wrong at the launch or how we got to where we are now. I think we all intuitively know that much. But what I would very much like to hear is what problems Asobo and Microsoft acknowledge still exist and what is the plan to fix them.

Much of the frustration from the community arises from reporting the same issues over and over since launch and never getting any acknowledgement that the problem is recognized. Yes, posts sometimes get marked as “bug logged” but then it’s never mentioned again. If we were to receive any information about what the underlying problem may be and what path might lead to a solution, I think much of the unrest here would die down. At least we’d know that it’s actually being looked into.

As it is, we are left to grumble amongst ourselves and many obviously talented folks actually do quite a bit of debugging on their own to try to unravel things. I’m often amazed at how insightful some of the community here can be. Asobo is making a mistake by not leveraging this talent by bringing them into the loop. There is an entire community of testers available FOR FREE, if only they knew specifically what and how to test.

Yes, I’m familiar with the beta program and have participated in every iteration thus far. But it feels like tilting at windmills when we are provided little to no information as to what has been changed, ie. “Just test everything and let us know”. And then when a problem is reported, such as the overly lit POI’s that reappeared in SU 6 and was reported fairly early in the beta, it still got pushed out unfixed in the final release.

Plus ça change, plus c’est la même chose.

I think you have identified one of the most important parts of the problem.

At this point, I am not particularly interested in another retrospective explanation of what went wrong at launch either. Nor am I asking Microsoft or Asobo for another general statement saying that they are listening to the community. What I would like to see is something much more concrete: a public and reasonably detailed picture of the current state of the simulator.

Which major problems do Microsoft and Asobo acknowledge are still unresolved? Which are actively being investigated? Which have a known root cause? Which are considered priorities? And where a solution is not yet known, simply saying so would already be useful information.

I don’t think anyone can reasonably expect a release date for every bug. Software development doesn’t work that way. But there is a very large difference between “we cannot yet tell you when this will be fixed” and months of silence after “bug logged”.

Your point about the beta programme is particularly important. If users are volunteering their time and hardware to test these builds, Microsoft and Asobo could make that effort enormously more valuable by telling testers what has changed, what specifically needs validation and, afterwards, what was learned from the reports they submitted. That is not merely communication; it is part of running an effective beta programme.

There is also another consequence of this lack of feedback that I can only describe from my own experience: eventually, you stop trying.

MSFS 2024 is still installed on my computer, but for all practical purposes I have put it into storage. Not because I have lost interest in flight simulation — quite the opposite. I have simply moved on to other simulators which may be less visually spectacular, but give me far more satisfying and consistent experiences.

I would genuinely like to have a reason to come back to MSFS 2024. But after repeatedly checking updates and finding that problems important to my experience remain unresolved, while often having little idea whether they are even acknowledged or being actively addressed, I eventually got tired of testing whether the next update would finally be the one.

And, just for context, this is not happening on a low- or mid-range system. I am running a Ryzen 9 9950X3D, an RTX 5080 and 64 GB of DDR5 memory, with a Quest 3 for VR. Hardware and configuration can of course influence individual issues, but I don’t think insufficient hardware is a convincing explanation for the overall experience I am describing.

I suspect this is ultimately a more serious problem for Microsoft and Asobo than angry forum posts. An angry user is still engaged. A user who simply stops launching the simulator is not.

And this brings me back to the reason I started this discussion. These are exactly the questions I would like the specialist press to ask when they have Microsoft and Asobo sitting in front of them.

Not only “what exciting things are coming next?”, but also:

What important problems do you acknowledge are still present in MSFS 2024 today?

Which of them are your priorities?

Why are issues reported during beta sometimes reaching the public build unchanged?

What happens internally after a community report is marked “bug logged”?

And what are you going to change so that testers can actually see that their work is contributing to the development process?

I think clear answers to questions like these would do considerably more to rebuild confidence than another list of future features.

And if Microsoft and Asobo are willing to answer them in detail, I would genuinely welcome those answers.

On the other side of this coin are the almost limitless variations of computer hardware, user expertise and levels of expectation that cannot possibly all be satisfied by one, as you describe it, “enormous and technically ambitious simulator”.
Far more often than not, every “it’s dreadful and causes me nothing but problems” is offset by “it’s wonderful and works exactly as I want it to”.
I have spent a long time on the edge of the world of flight simulator developers and in my experience, they are highly reticent when asked how things are going, or what they intend to do.
It seems that every action that a developer may do can have unintended consequences that we have all seen no end of times, since home computer flight simulation became a thing.
If I worked in that world, I too would not be as forthcoming as you would like them to be, for fear of ending up with both egg on my face and providing another truckload of ammunition for my critics to feast on.

One of the most recent examples of how critique can be and indeed was, heard and acted on is the remanufacture of the Local Legends to a standard that I think, none of us expected.

My own humble and possibly worthless opinion is that MSFS 2024 is almost miraculous in comparison to what was possible a mere say thirty years ago.

Although I agree that there is always room for improvement, we should in fact talk more about what we have and a little less about how individual parts do not satisfy individual needs and what is deemed by some to be wrong with it.

I don’t have rose tinted glasses and I have shared in the frustrations, particularly when an update restores previously resolved issues, or creates issues with existing addons that were not there before.
However, that is the nature of an evolving simulator, something which for many of us is a stark contrast to say FSX, which has been stable and unchanged for almost 17 years.
Yet there are still those for whom FSX causes nothing but trouble.

I think your point of view is very reasonable, and I agree with much of it.

MSFS 2024 is an extraordinarily complex simulator, and with the almost unlimited variety of hardware, peripherals, drivers, user knowledge and expectations, no developer can possibly guarantee exactly the same experience for everyone. I also agree that every change in a simulator like this can have unintended consequences, and that developers therefore have good reasons to be cautious when talking about future fixes or commitments.

Where I see a problem is in the consistency of that caution.

I fully understand the argument that developers should avoid making promises they may not be able to keep. But that level of restraint was not always present when MSFS 2024 was being presented and expectations were being created around its launch.

My point is not simply “you promised and failed to deliver”. Software development is much more complicated than that. What I find difficult to reconcile is very confident communication when expectations are being created, followed by much greater caution when users later ask what remains unresolved, what is being investigated and what the priorities are.

I think it is reasonable to expect a similar level of clarity in both directions.

I also completely accept the point about hardware variation. Different systems and configurations will inevitably produce different results.

What I find harder to accept is the scale of those differences, particularly when we are talking about high-end or very high-end systems.

Some variation in performance, stability or visual quality is perfectly normal. But when one user can describe the simulator as working almost perfectly while another, on hardware that is clearly not limited by lack of CPU, GPU or memory, encounters persistent problems that fundamentally affect the experience, I think it is fair to ask whether hardware diversity alone really explains everything.

And there is another reason why I do not think hardware variation is always a sufficient explanation.

If one public release runs reasonably well on a given system, with a given configuration, and the next public release on that same system and essentially the same configuration makes the simulator almost unusable, then we are no longer simply comparing different users with different PCs.

One of the main variables that has changed is the software itself.

Of course regressions can happen in any complex piece of software. But there is an important difference between finding a serious regression in a beta and shipping that regression in a final public release.

A beta is precisely where I expect instability, regressions and experiments. A final release is where I expect the testing process to have caught at least the most serious regressions, particularly those that fundamentally affect usability.

That does not mean every public build has to be perfect. That would be unrealistic. But when the same hardware can move from a reasonably good experience to an almost unusable one simply because the simulator has been updated to the next final release, I think it becomes difficult to explain that primarily in terms of hardware diversity.

At some point, “PCs are different” stops being a complete explanation and becomes only one factor among several that need to be examined.

And this is also why I do not think greater transparency necessarily means making risky promises.

Microsoft and Asobo do not need to say “this bug will be fixed next Tuesday” if they do not know that. But they can still say:

“We acknowledge this issue.”

“We are investigating it.”

“We believe we understand the cause, but we are not yet certain.”

“This is currently a priority.”

“We do not yet have an ETA.”

That kind of communication does not create unrealistic expectations. In my view, it helps manage them.

I also agree with you that MSFS 2024 is, in many ways, extraordinary compared with what was possible thirty years ago. The scale of the world, the weather, the visual technology and the ambition behind the simulator are remarkable.

But I do not think admiration for what the simulator achieves and criticism of what still does not work are mutually exclusive. Both things can be true at the same time.

In fact, I would go further: the fact that MSFS 2024 can be wonderful, even spectacular, when it works properly makes the inconsistency more frustrating, not less.

Nor do I think individual experience should be dismissed simply because another user has a different one. My experience does not prove that everybody has the same problems, just as somebody else having a flawless experience does not prove that those problems do not exist.

The useful question is whether recurring reports reveal patterns that Microsoft and Asobo themselves recognize.

So for me, the issue is not that MSFS 2024 is complex, evolving or imperfect. That is expected.

The issue is whether users can clearly understand which significant problems are known, which are being worked on, which are considered priorities, what changes are causing major regressions between releases, and what is being learned from the feedback the community provides.

That seems to me a perfectly reasonable expectation, especially for a simulator whose development depends so heavily on an active community of users and beta testers.

And I think clearer communication on those points would reduce frustration considerably, without requiring Microsoft or Asobo to make promises they cannot safely make.

Don’t worry msfs2028 will be here soon enough and then we will all be back to square one.

Not only clearer communication but a) more frequent communication and b) communication that gives us more time to express views in a conversation. One sided sound bite conversations are not helpful nor is the system of question submission because inevitably the difficult ones are avoided or side tracked.

When last did we have a twitch channel session - I think it was April or May. It simply is not gracious to be ignoring your customer base like this!

That is exactly what worries me.

If MSFS 2028 eventually arrives, Microsoft should not assume that everyone who bought 2024 will simply start again from square one.

Speaking only for myself, they would have to convince me first that the lessons from MSFS 2024 have actually been learned: better stability, fewer serious regressions between public releases, a more consistent VR experience, and above all much clearer communication about known problems and priorities.

I am not saying I would never buy another version. I am saying that next time, expectations and promises would not be enough.

The product would have to prove itself first.

I agree. Frequency matters just as much as clarity.

A communication channel that only opens occasionally, and where users have little opportunity to challenge or follow up on an answer, is not really a conversation.

That is also why I think the current question-submission format has limitations. It can be useful for organising a session, but if the difficult questions are filtered out, shortened or easily sidestepped, it does not really address the underlying frustration.

What I would like to see is not constant developer presence on the forum, and certainly not individual technical support through public discussions. But there should be a much more regular and genuinely two-way communication process.

If Microsoft and Asobo want the community to keep testing, reporting, discussing and investing time in the simulator, then maintaining that dialogue seems to me part of respecting that community.

You are so right - a whole army of employees for free who never get a sound bite of a response back is very disrespectful. After all, it is those testers who spend their valuable time giving and giving to MS/Asobo, they (MS/Asobo) who are reaping the financial rewards off the Beta testers backs.

I understand what you mean, although I would probably phrase the financial part a little differently.

Beta testing is voluntary, and I assume most of us who participate do so because we want to help improve a simulator we enjoy and have an interest in. I don’t think Microsoft or Asobo owe beta testers compensation simply for participating.

But I do think they owe that effort some meaningful feedback.

People are contributing their own time, hardware and experience to reproduce problems, test changes and write reports. The minimum return does not have to be money or individual responses to every report. It can simply be communication: what was useful, what was confirmed, what is being investigated, what needs further testing and what changed as a result.

Otherwise, after a while, people inevitably start asking themselves: why am I spending my time testing this if I have no idea whether anything I report is making a difference?

And that is a shame, because a large and technically knowledgeable community willing to test your software voluntarily should be an enormous asset, not a resource that eventually becomes exhausted through lack of feedback.

Yes, I did not imply any financial reward, rather the respect of communication - I added a bit to make it clearer.

I would like to see things fixed on the current simulator rather than see what the future holds…There are still problems that need to be addressed and yet the software people do not seem to want to fix them. They are all probably working on the next FS project and have no time to fix the current problems.

The one thing I would like to see addressed is the control mappings which is way to complicated and time consuming. If you look at how X-Plane does the control mappings it would be a good example for the software people to emulate. FWIW

Unfortunately many of us have tried to get through to MS/Asobo/Community Mods over the years about the poor standard of beta practices, especially regarding the severe lack of communication during those periods and yet we’re persistently met with a wall of silence. After 6 years it’s very apparent they have their ways set in stone and refuse to acknowledge where they can do better, we’ve tried countless times with descriptive ways to improve and yet nothing ever changes, even when it’s so blatantly obvious a small change could benefit so greatly.

I’m sorry to inform you but threads just like this have appeared and disappeared over the years without notice as well, they say “we read everything” which is one thing, but they never put into action what they read. They simply do not take constructive criticism onboard when to comes to improving the fundamental basics of beta periods, instead it gets flagged, hidden and eventually these threads tumble down the board to be forgotten about

Fundamental change is required but it won’t happen, 6 years of no changes has proven that, they’re probably focused on MSFS202X by now and that’s a whole other story.

If Microsoft and Asobo are already working on the next instalment, then speaking only for myself, they should not count on me this time.

After my experience with MSFS 2024, I would not buy another version based on promises, presentations or expectations created before release.

They would have to prove first, with the actual product, that the lessons from 2024 have been learned.

If they are already working on the next version, then for now they can count me out.

MSFS 2024 has used up a lot of the trust I had in this project. I am not interested in starting the same cycle again with another round of announcements about what the next simulator is going to be.

Finish this one properly first. Then we can talk about the next one.

I could not agree more! (pure speculation from my part on the next version BTW)

I guess this begs the question of why Microsoft and Asobo don’t listen to users complaints and just keep going in the same direction??? I assume it is $$$ based.

I would guess they are not allowed to. And if I were in that position as a developer, I would completely ignore the forums, because it would be way too frustrating to not be able to say anything when you might know exactly what the root cause of a specific problem is, while also knowing that the fix for it is number 362 on a priority list of 500 items.

So I have to imagine that the MS/Asobo staff who are “following every post” on this forum are more at the corporate Product Manager or even Project Manager level. In other words, people who are already one or two degrees of separation away from the developers performing the actual coding work.

My own two cents: First, @fjcaneda , totally agree with your viewpoints here. Another factor to consider in the communication gap is the practicalities of organising and coordinating a public communication “event” like a developer livestream, or even an official “statement” for a post. And historically speaking, aside from announcements of content like City Updates or Local Legends, and the occasional technical demo of new and upcoming features (eg turbulence modeling) many of the team’s more off-the-cuff answers to the presubmitted and live questions have largely been aspirational rather than based on actual planned work-in-progress.

How many questions (especially when you consider developer streams held when MSFS 2020 was the only sim they were working on) were answered with some form of “We will take that into consideration” or “we will look into that” for issues that then dropped completely off the radar and never appeared in a Beta. Not that anyone was being intentionally misleading. Jorg and team are obviously also excited about and invested in this product and want the best from it as much as we do. But when it comes to the realities of what work can actually be accomplished within a given timeframe and with the resourcing at hand, aspirations rarely meet reality.

You know what I miss more than developer streams? The “Lifetime Bugs” and “Lifetime Wishlist” snapshots that used to be released on a weekly basis. Those lists allowed us to see and loosely track which issues were “Under investigation” or “In progress” or “No repro” or “Fixed”. And it made it more obvious that if you took the time to contribute to and vote for a bug thread, that issue would show up higher on the next update to the list.

If these snapshots could return on at least a monthly basis, it would answer some of these questions (what are the priority bugs and wishlist items being targeted for the next beta and update) without us needing to ask them.