This will continue to be a challenge because humans are simply not great at estimating. I have had success by explaining to managers that a big part of my job is to help them manage risk. In order for me to do that properly I typically need more information than is initially present so that I can give a high confidence estimate. I might say something like, "I can give you a low confidence ball park estimate right now but if you give me a few hours to research then I can greatly increase the confidence level."

After all, you know the least about a project at the beginning therefore no one should have a high degree of confidence in estimates given then.

Yeah, this was how I was trained to do it. A ballpark estimate on the spot at best is around 30% accuracy. I normally wouldn't give an estimate unless I can break it down the work into less than 4 hour chunks. Proper estimates also contribute to work done as it involves the design, but it's normal to spend a few hours doing estimation.

Trained managers are familiar with the cone of uncertainty, though.

But what I really mean is stuff on the level of powering a toaster with a car battery. It's certainly possible, but nobody has documented on what they did, and there's a very high number of uncertainties as neither were designed to perform this way.

I think you nailed it by pointing out how overlooked the research part of development is. Technical folks often understand this but it can be a challenging concept for people who have not worked as a developer. They can have a distorted view of the research to coding ratio. I imagine they often believe that writing code takes up 90% of a developer's time when in reality time spent researching and thinking is the dominant activity.