Yes, I meant the back end is Object Oriented. And the whole point of mentioning that stuff was to head off any discussion about it.
And the PSR guidelines are mainly focused on code naming conventions and white space (spaces vs tabs), not the actual algorithms you're creating. Just like the PEAR and Zend coding styles. They have nothing to do with the code itself, just how it looks and making it easier to know what's what when you're looking at it (maybe not quite so much with PSR-0, but that's just a recommended namespace/folder structure for auto-loading classes if that's your thing, and haven't really looked too far into PSR-3 yet).
But this thread doesn't have anything to do with that. I'm just curious about feedback regarding the data structure.
And this data structure does have a lot to do with setting up a CMS if it's part of the API you're creating for plugin developers. In the back-end I'll be parsing that array and setting up and creating the features/routes/permissions for pages and blocks, along with allowing other plugins the opportunity to override any settings and add to the settings without having to touch another plugins code base, while at the same time allowing the back-end to check for any conflicts inside the plugin overrides, and any conflicts with other 3rd party plugin overrides, before executing the overrides so it can exit gracefully instead of having strange side effects or just blowing up on you.
And I believe this structure will allow me to add to it in the future without breaking existing plugins; like adding more properties (i.e. permissions); or different content types (i.e. pages, blocks).
So with those things in mind, is there any additional feedback?