I understand what you are talking about and almost agree. The site builder might want to replace those modules with their own variants or perhaps an alternative admin template uses its own modules for this

Yeah, those are both legitimate concerns. Dropping the title module just creates some visual problems, so it's less of an issue, but dropping the menu and toolbar can make your backend unusable. So right now I kind of lean toward the "these are critical capabilities and maybe that means we should sacrifice a little flexibility out-of-the-box" side of the line. Alternative templates would be able to use modules as the case is now, hardcode their own module implementations, or whatever the case may be still.

Is there any argument for having that if the module exists then the hardcoded element is replaced by the module position?

You also forget that with the current module system a site owner can move these "critical" modules to different positions.

In conclusion it is either a template with modules etc or a complete application. I don't believe you can have both . My 10c

This is one of those times where I really feel like having capabilities exposed in the UI can let a user shoot themselves in the foot way too easily (same argument can be made for authentication plugins). Having a truly modular backend is not something we designed Isis for, and I guarantee the 4.0 work won't be either. Sure, some stuff can be moved around and things display OK (move the toolbar to the title position, it works but you've still got the sticky navbar that's now empty), but there's also some magic in Isis at least that means if you move some things out of position they don't display right at all (i.e. change the user status module to the footer position instead of status).

So I don't think it'd be an extremely terrible thing to hardcode some stuff direct into the template, unless we're going to commit to a properly modular admin template.

All things considered I think my preference would be to also hardcode these elements. It is certainly the easier option. The alternative involves a lot more considerations for largely edge cases.

So hard code all the modules that are part of the ui. ie everything that is not a dashboard item.

@mbabker I've already started something for this: https://github.com/joomla/40-backend-template/compare/master...dgrammatiko:html5-please?expand=1

Obviously for the same reasons that you mentioned above I totally agree...

Seems that we already have modules hard coded into components now.