Deleted Comment
It would appear to me that they have already lost the innate curiosity (if they ever had it) that made them want to become doctors in the first place.
Or they're not confident enough in their ability. Doctors are already paid substantially compared to most other professions, so for them to not put in extra time on the exceptional cases makes me feel they probably feel entitled. Too much so to have any impact on the rare cases.
The doctors who could realistically find the solution are the ones who will likely want to take the case on for free.
I've had a number of comments here on HN related to this. Imagine this same scenario, except instead of the User being in charge of deciding which engine is used to render a website / webapp, the Developer is making that choice. What would a developer need to do if they were in control of which "engine" rendered their website on the user's computer?
Instead of being at the mercy of Google / Chrome, the developer of said site could simply change their HTTP Header "X-BrowserEngine" or something like this, and the client's computer would know how to (a) download the new engine if it's not on the computer already (b) sandbox the new engine (c) run the site / app in said engine.
I've called this idea the "Meta Browser" in the past. It's a concept for an app that sandboxes and runs sites on different browser engines seamlessly. The user experience is more or less as though they're continuing to use a single app to browse the web, but behind the scenes could be any number of custom engines rendering the content.
If your idea were implemented, I'd expect that in 30 years someone will propose the meta-meta-browser so developers can choose the meta-browser that hosts their chosen browser engine.
Effectively you'd have web and newweb tabs side by side. You'd get some of the Chromium infrastructure 'for free', like user switching, the nice tab dragging code and so on. NewWeb tabs would not contain the URL bar, back button, reload button, bookmark star, extension buttons etc. But it might reduce some of the mental overhead of having to switch between 'browser' apps.
The "new tab type" idea sounds like it fits. In a way I see the "browser renaissance", that I think (hope) is going to happen within the next decade, is also more than just about sandboxing browser engines. When you follow the line of thought further I think the browser core becomes supported by a set of decoupled libraries which will be reused by different browser engines.
I think the toughest hurdle to this kind of thing is probably abstracting away the details, but still making it possible for end users to make educated / granular decisions so that they can understand more or less what the security implications of certain actions / settings would be. I imagine those 2 things (user knowledge and need for abstraction / shielding users from themselves) will eventually converge to a happy middle ground. But for starters could (for the least knowledgeable users) probably be something like providing a handful of options like "extra safe", "safe", "maybe trouble", "danger zone".
Though to be fair "danger zone" would probably mean something different than it historically would, since the "shell app / meta-browser" hosting the browser engines in theory would prevent an application from escaping its sandbox, but instead could allow an app, within the confines of the user's settings, to do things the user didn't expect.
My solution to the "new web" problem is radically different (though to be fair, trying to reinvent the web is in itself a radical idea).
I've posted my idea to many similar threads, so I apologize for repeating myself, but I feel pretty passionately about it and I feel it's a good idea to try to spread. Until I start receiving convincing evidence / arguments that the idea isn't worth spreading I'll probably continue.
Imagine if we didn't have to decide what the "new web" was going to be, BUT we did allow that experimentation to take place? I say we shouldn't make it a requirement to "convince people it's the right thing to do before it gets built and people start using it".
What if users didn't use "browsers". Instead they used "meta browsers". An application which hosts browser engines. And not only could apps / documents / etc. be downloaded by this "meta browser", but the experience of switching between browsers was also seamless to the end user. If they didn't already have that browser engine they would be prompted to download it if a particular app / document developer decided they were supporting it.
In this "new web", the "document / app" developer decides which browser engine the "meta browser" should render their app with.
What if a browser engine developer decided he didn't want to support RFC https://tools.ietf.org/html/rfc3986
It probably feels like they're on a suicide mission (for their browser), but why should it be a "requirement"? If the ideas are bigger and better and eventually catch on (ie. things we haven't even thought of yet) why should "the web" somehow dictate what core set of ideas are the right ones?
I say this because I was recently hired to work on a project where managers are obviously the only ones responsible for deciding how a developer should function within the organization. It is obvious the state of the project is anything but healthy at the moment. Attrition rates are astronomical and the code is beyond ugly in a lot of cases.