Nickolay, under no circumstances you should give more flexibility to the themes by allowing it to control the components - this will lead to tremendous problems with the plugins update, since the theme would never know what changes have been made in the plugin to clone them during the update and vise versa. And more over will bring a lot of dependencies between themes and plugins which can break the site functionality in case the plugin/theme developer timely considers their joint behavior.

The second aspect of negative consequences of  these changes is related to the clumsy, unprofessional and confused code caused by mixing up the renderable and the theme logics. These are two absolutely independent functionality and in no way shouldn't be tied to each other.

Hereunder, it's highly unrecommended to make these changes and use the code provided above.

I cannot agree with you on this. It's not a question of breaking functionality on updates, but really giving an opportunity to create unique websites. As of now every plugin/theme in Store has compatibility tag regarding different Oxwall versions, and that's absolutely ok - any developer or user that has custom plugins on his/her site needs to check and test everything when a new release comes. Any other cms/platform would require it, before updating a working website.

Refuse flexibility just as being afraid that someone will break something is not a very clever way to go, because customizing output html is the base for the user of any web-platform to give ( Oxwall is already using Smarty for this and does not store any sirious logic in templates - it is the purpose of this template engine actually to ease layout customizing). So you can either pretend this problem does not exist at all and users will just have to hack the core or give them a useful instrument with basic explanation on how to use it. It's your choice.

Seems you a little bit confuse the above-mentioned conceptions. Since this topic is quite popular, but your solution can lead to negative consequences in future, I want to try to define the way it should work and really work once again.
 
The modification you are suggesting is good enough in case you need to create something right here and right now, but not thinking about the long-term software (feature) development. In case you decided to perform the software or themes update or make any other modifications - this solution would become such a pain in future.

Our software architectural pattern is MVC, that's why the software includes effective segregation of logic (functionality) and view (templates). This is fundamental solutions for most of the softwares presented on the market.

Nickolay, our software is the platform which allows you to integrate any third-party functionality without main(core) functionality penetration. i.e. if you need additional functionality or customize some component for certain theme - you can create an additional plugin with the code which will affect the view of this or that template part. By the way, we already have some themes which go along with the additional plugins.

We can argue about this all along, but this solution is not even about adding some additional functionality - it's simply about styling. And about MVC: let's take any popular mvc-based CMS or framework and look if template/layout overrides are present in core functionality. It always is. And there's a good explanation why - 'cause "View" does not need to perform any complex data operations, it's there just for presentation of it (and the actual data structure is rarely changed in minor releases).

And it is wrong in concept for example when a user needs (or client asks a developer) to have some "cosmetic" changes in registration form or else (have you ever tried to apply custom created design to Oxwall?), you personally tell them to go and create new plugins with core functionality that already exists. It's just wrong and time unefficient.

So when you say "our software is the platform which allows you to integrate any third-party functionality without main(core) functionality penetration" it's not really true - facing "real-world" tasks (just look at questions in this forum section) shows you there's a quite large space for improvent of flexibility, like additional types of System Events and so on. This solution is one of those that are needed here.

This solution contradicts Oxwall theme development conventions. In no way we want to argue about this solution, we just want Oxwallers to know our official position.

We are working on the software development more than 10 years and clearly knowledgeable about all possible bottlenecks with the overriding of the components templates through themes. That's why we gave a possibility to  override the templates through the master pages and decorators only. This gives theme developers an opportunity to change the general site structure, but prevents conflicts between theme and plugins.

As for the modification - yes, for now there are a lot of situations which were missed, but our Events system is regularly improving and on a constant basis we are adding new methods which allow to make modifications by creating third-party plugins without changing the core functionality.

Your solution is the solution, but we just want to emphasize once again that we do not recommend using the solution you provide - nothing more.

Unfortunately master pages and decorators are very limited as for now to actually say that it's helping to change general structure, so needs iprovement here too.

Don't take it personally, but Oxwall as of today really lacks the look individuality for projects without custom dev intrusion, though its core functionality is more than great. And the first post of this topic is the simplest way I saw to solve it. Consider this just an outside point of view, I have no doubt that DEV Team will find the right decision to make in future.