This never made sense to me. It never made sense to me when the other control panel was doing the same. The other control panel eventually changed to making updates separate. DirectAdmin always had them separate until they decided to merge them together and that decision could very well be it's undoing if you ask me.
You have to look at servers in terms of a stack. A control panel is just one piece of the puzzle. It's not THE piece of the puzzle.
In terms of what we've come to know in terms of a shared web hosting server, there's basically three main parts:
A web server - Apache, nginx, Litespeed, etc.
An MTA - Exim, Postfix
An IMAP/POP3 service - Dovecot, Courier (?)
Most everything in terms of shared web hosting revolves around these 3 main parts. Certainly PHP is the most popular programming language of choice for most users of the web server. You can argue that PHP fits in there some where, but I'd argue that it fits under the web server.
All that a control panel does is provide an interface for controlling these parts of a shared web hosting server. The only time a control panel should be concerned with the versions of these core software parts, is if one of those core softwares changes the way they are configured. If Apache suddenly changes to a JSON type VirtualHost storage system instead of their known VirtualHost containers - then the interface that the control panel provides will have to change to fit that configuration. How often does this happen?
As for PHP, I don't really understand where it fits in the control panel. A change in the way PHP interfaces with it's web server is a concern for the web server and not the control panel. Perhaps a better solution, and one that I strongly agree with, is that if the control panel is depending on PHP... then package it's own PHP into the control panel interface. If the control panel wants to use PHP 5.6 for all of it's control panel interfacing, then use PHP 5.6 in the control panel interface. If the control panel wants to use nginx as it's interfacing web server, then include it's own nginx system to provide that interface with the control panel.
The control panel itself should be self-contained. Sure it's going to depend on the existence of some system libraries and binaries (which can lead me into the topic of DirectAdmin supporting every Linux distribution under the sun, but that's veering way off topic). But when the control panel starts to mingle with the, what I'll call the "public Internet facing software", that's when problem arise.
If you are familiar with using pre and post hooks in control panels (which admittedly, DirectAdmin has a lot to offer here) then you basically have to understand that all a control panel is doing is a set of these pre and post hooks. If you go to create an account and enter a domain name, a username, a password, and a package. When you click submit all the control panel is doing is parsing that information through a series of pre and post hooks (most of which are invisible to server administrators, but they are there). It takes that information and configures a VirtualHost, configures the MTA and IMAP/POP3 services to work with this user and domain. If the only thing a control panel did was pass the information submitted from that create an account form into a hook - then essentially the server administrator would be responsible for fashioning the hook in such a way to configure the services as needed.
When you log into your DirectAdmin control panel interface, i.e. https://%server%:2222/, or whatever port you have this configured on. That's the control panel interface. That should be self-contained. It shouldn't care what web server or what web server version you are using (as long as the control panel knows how to add/modify/delete configurations for it). Or what PHP versions you have installed. It should all be self-contained.
This path that CustomBuild has taken in its reliance on DirectAdmin version, is a huge step backwards - in my opinion.
), which I always use for Composer, for example.
