I understand where you're coming from. I might have come off as a little "this is better than that" unfortunately.
What I meant to express is how I personally see our types of work relating to non-software engineering professions. For many physical engineering disciplines there's some type of external regulatory body that you must measure up against for each project you complete, to have that project approved to be "launched". In the UI example: if there's no external body that has to sign off on your work, you can pretty much do whatever the heck you want to get that gorgeous interface in front of a user. The skill required to do so may well dwarf my own, with a million crazy frontend js libraries, web standards, and so forth to memorize and wrangle (not a UI guy, obviously). But in my own admittedly narrow definition, as the work can be done without being answerable to some external body that has to sign off on it, I couldn't call that engineering. Again, it doesn't mean the UI work isn't complex, requiring highly skilled individuals, etc. Of course even safety critical software engineers don't have a regular recertification required. Given that and other differences, even this application of the term falls short in comparison to other disciplines.
For the record, I'm still of the mind that "real" engineers are those individuals trained to create physical things built to withstand innumerable stresses, structural material complexities, manufacturing hurdles, and so forth without endangering lives or risking property damage. We software types have sort of usurped the term, for better or worse. It's here to stay, but some kind of indicated specialization known widely beyond our industry could help.
Regarding "full stack" though, there are areas of certain software-heavy industries where that term doesn't matter. Take an avionics "black box" for instance. It can be a strictly embedded device with no concept of a PC-type environment. They almost universally run some kind of RTOS or compartmentalized RTOS, and perform a short, known list of master tasks (10-20 for instance) that will never change. They talk with various hardware in the aircraft and through radios on the aircraft to a variety of ground stations, satellites, and other aircraft. The standards they adhere to (for the physical wiring from box to box, the protocols on those wires, the way the software is designed, etc.) can be 20-30 years old. Those standards can be updated sometimes never, sometimes 2 or 3 times over that span. There's no concept of constantly changing software libraries because it's so SO ridiculously expensive to go through a process called "certification" that reports on exact versions of software working on exact versions of hardware, and then you don't change a thing (not a single resistor, not a single bit) unless you have a very good reason to. Besides knowing your embedded software/hardware craft, the companies that build these boxes want engineers steeped in the guidance and rules of the appropriate regulating body (in this case, the FAA). There's a rep from your company (but representing the interests of the FAA) looking over your shoulder, so to speak, called a DER. That person's job is to put their ass on the line for your company, to the FAA, saying you did what you were supposed to. You have to highly specialize in order to do your part correctly so your DER can do their highly specialized part correctly, so the FAA can approve your company to sell said black box to aircraft manufacturers with an FAA seal of approval. It's a ridiculously intricate, expensive, and time-consuming process that helps to ensure air travel is generally extremely safe. The FDA is about 20 years behind the FAA in terms of dictating what and how, but similar concerns, processes, and regulatory hurdles apply. There's extreme rigor required in these fields, and extreme specialization, because if you screw up you can kill somebody (or lots of somebodies).