With a bit of delay, most of your concerns have been addressed in the current trunk, and should find their way into the upcoming 2.3 release:
> However, if UserA first clicks on a page that he can edit, and then clicks on a page he can't edit, then the buttons down the bottom of the content view still show on the page he isn't supposed to edit, AND if he clicks on them they do actually perform their function (e.g. Unpublish or delete!)!
Just tested, opening an editable page followed by opening a readonly page hides the buttons. The permissions should be enforced regardless on the controller now. Can you confirm?
> The fact that access permissions were not applied down trees of pages.
Theres a new option "Inherit from parent page", which is then used in SiteTree->canView() and canEdit().
> That you can't add multiple security groups to the Access settings of pages.
Fixed, its now a many_many relationship
> That one single user can't belong to multiple security groups (not 100% sure on that one)
Hm, that was possible since 2.0 afaict.
> The unfriendly URLs (to me non-hierarchical URLs are only slightly more useful as having the old page.php?pageid=1234)
Thats being addressed in a feature branch at the moment: http://open.silverstripe.com/browser/modules/sapphire/branches/nestedurls
I'm just working on a migration script which will transfer data from the legacy columns like the ViewersGroup has_one relationship to the new schema.
The changes are mostly unit tested, but we might have missed some assumptions and controller actions where permissions aren't fully enforced, so any manual testing and feedback is welcome! :) FrostySonic, any chance you find some time for this?