It's been suggested many times over the years, but there are some things that make this more difficult than it seems at first.
1. MC is
constantly changing. I think they average 4 builds/week in the beta forums, and probably 4/month in the public forums. Even with only 5-7 changes per build, you're looking at 100+ changes per month, or over 1000 per year. Many are bug fixes, but there are lots of enhancements or changes, sometimes even reversing previous changes/improvements for various reasons.
2. No one knows all the intricacies better than the developers, but there are only 4 full time (I think) developers, and if they were documenting all the changes, they wouldn't be making the changes, and we'd all suffer.
3. The wiki attempts to do the very thing you're requesting, and is mostly user contributed/updated, so it doesn't have all the stuff that MC can do, partly because of the reasons above.
4. Everyone uses MC differently. Some users have LOTS of highly customized views, often with complex expressions driving them, for a very specific purpose, which isn't normally easily transferable to another user need. Some are content with the basic functionality. As a person uses MC more and more, they tend to learn more and more, and adapt their system to their specific needs and wants.
It's very difficult to give a 'this is how you do it' type explanation, since everyone comes with different media storage setups, different needs, and a WIDE range of computer knowledge and experience. What seems absurdly easy to one user is still over the head of another user.
5. Part of the joy of MC, for me, is visiting the forums and seeing what others are requesting, and the resolutions suggested by others. I learn a lot by coming here and just poking around.
I realize that I'm in the minority in this, and that most users won't have the time or interest to do this, and a basic 'how to do it' manual would be welcome/useful, but those that could write it typically prefer to help in specific requests or situations vs. taking weeks/months to write a manual that will be outdated by the time they finish. Many contribute to the wiki (and we appreciate it!), and I think that's the best we can reasonably expect for the foreseeable future, for good or bad.
Also, I'm not convinced that this is the driving force behind the team at JRiver...
If JR wants to grow their big sophisticated program further...
I'm sure they would like to see it continue to grow, and Jim often posts about new levels of success they reach, but I think they do it more because they love it, and this community, than an overwhelming desire for growth. I think they'd rather spend time helping the nice folks here, than writing manuals, and I'm glad they do