That is because you are not engaged in the actual process of how things are decided. Most of these come in with long term discussion at project week or weekly calls, and there are importantly decisions. You can come and voice your opinion in those, and more importantly if you want to be in the driving seat about how those things are implement, find some funding (or dedicate your people’s time) to implement things that you need. You are welcomed to participate in all of these.
As a research tool, the needs of the slicer is typically determined by needs of the active funded projects that needs those. That makes sense, because those are the ones practically paying for all the costs of maintaining and developing the software. There is really no other money (apart from what Kitware donates in terms of computer infrastructure and their engineers time to make all that websites, extension manager, automatic update infrastructure to work). If there are conflict in needs, that’s usually handled in these meetings and usually come up with a solution, it may not be always great for everyone involved, but usually it is we find a fairly amicable and workable solution.
I will comment on the fcsv change a bit, because my group was involved in that. We created this great way of using blank landmark templates (so that everytime you get exactly the same number of landmarks in the same order, if you are not familiar check the video Landmark Templates in 3D Slicer (youtube.com). This required a major reworking of the markups module infrastrucre and addition of new properties to markups that contains the state of the markup (set, unset, in progress etc). This cannot be handled by the fcsv format. Hence the decision going forward to create the warning about fcsv format being lossy and that people should be saving their files as JSON to avoid issues.
I understand your frustration. My lab have been using Slicer over a decade now, and we probably have about 10-12 thousands fcsv files we have collected from our samples during this time. We gradually migrate them to JSON as we need. It is not difficult. This wasn’t the first time it happened, and I am sure it won’t be the last. When Slicer 4 was released, the markups (it used to be called annotations) were of a different format too (every control point was saved individually).
Big changes like this every decade or so is almost expected. These changes are not made because it makes developers life easier, but it is made because the biomedical imaging software tools (i.e., commercial and other open source tools) and community needs evolves over time. That means you have to maintain interoperability, you need to support new research directions and hardware changes. Ideally this should be done in a backward compatible way, but we don’t always have the resources.
This is where you come in. As @jamesobutler mentioned you can post you needs, and work with others on the community to express your issue and resolve them. If you can actually sponsor some of this work, then it is even faster. Becasue while the software is provided free, development and changes are not. And often these are not a lot of money. Depending on the ask and the scope of things, it might even cost less than an annual support contract of a commercial biomedical image analysis tool. Or a maybe the cost of a single seat.