The point with the manual, is that if you dedicate one staff member to writng the Comprehensive DS manual is that before everything could be covered in draft, things would already be beginning to need to be updated, so in effect it could never be completed. Say it has 20 Chapters by the time chapter 12 is reached it's likely that chapter 3 may need to be rewritten to adapt for some new changes being implemented. So hire more writers you say, how long before you have more manual writers eating into development budgets then you have software developers actually building the software. Sure you will eventually have an in depth manuals but also a frozen development schedule as well. The only way to write a manual in this fashion is to finish DS 5 stop all development, write a manual for DS 5. Then release DS 5 and sell for 2-3 years and eventually start planning DS 6. This isn't the development cycle of DS and in my opinion this would be a somewhat old fashioned development cycle in general. And I honestly hope they never move in this direction.

Also DS does in fact already have an online user guide "http://docs.daz3d.com/doku.php/public/software/dazstudio/4/userguide/start" though no prizes for guessing what the most common issue is with it, a lot of information is for previous versions and a little outdated.

•••

As modern software development is dynamic and often features live updates with ongoing patch cycles, bug finding and patching is an ongoing endeavor in the development of all live software. There is just no such thing as totally bug free or perfect software. Its also physically impossible to test software for every eventuality before it's rollout. 

•••

So your issue with DS 4.8 is that you're having issues with a 3rd party plugin by (Gofigure)? So maybe Gofigure need to write a manual for Animate2? http://gofigure3d.com/site/index.php?option=com_content&view=article&id=92&Itemid=86 ... Though it's probably unlikely to cover your particular issue as even manuals don't cover every aspect. The best place to get a potential solution is likely in a forum. 

The point really wasn't blue or yellow, it was that developers need to prioritise where to spend their development resources. While a colour picker may be high on yours and some others list and perhaps developers have it on their radar as well, but have looked into the issue and decided their time is best spent elsewhere for the time being. Potentially a little like the PS bridge issue you have described. Maybe developers are already spending time developing new components that will make the marked issue irrelevant in the future. Why should they stop what they are doing just to spend time to create a quick immediate fix to a small issue. It's easy to end up playing whack a mole and lose focus for the future development of the software going down that path.

If you have found a bug or even have a suggestion, I would suggest reporting it through the correct channels, as that's the most likely action to result in seeing a fix/change implemented in the future.