Since we're trying to be lesswrong here, I'll risk seeming petty by pointing out that "begging the question" is a logical fallacy, not a synonym for "raising the question". Just sayin...

That only works if there are few levels of abstraction; I doubt that you can derive how do programs work at the machine codes level based of your knowledge of physics and high-level programming. Sometimes, gears are so small that you can't even see them on your top level big picture, and sometimes just climbing up one level of abstraction takes enormous effort if you don't know in advance how to do it.

I think that you should understand, at least once, how the system works on each level and refresh/deepen that knowledge when you need it.

just as I'd expect a competent software engineer to be able to write a hash table by hand even if every environment they're likely to encounter will have built-in implementations or at least efficient libraries for it.

I have a feeling that's a bit of a relic.

Long time ago programming environments were primitive and Real Men wrote their own sorts and hash tables (there is a canonical story from even more Ancient Times). But times have changed. I can't imagine a serious situation (as opposed to e.g. a programming contest) where I would have to write my own sort routine from scratch -- similarly to how I can't imagine needing to construct a washing machine out of a tub, an electric motor, pulleys, and belts.

I certainly still care about performance properties of various sorts, but I don't care about their internal details as long as the performance properties hold. I suspect that the interview questions of the "implement a bubble sort on this piece of paper" variety if anything aim more at "have you been paying attention during your CS classes" and less at "do you have a deep understanding of what your program is doing".

The capacity of human minds is limited and I'll accept climbing up higher in abstraction levels at the price of forgetting how the lower-level gears turn.

I'm thinking more specifically than you are. Rather than learning probability theory to understand ML, learn only what you determine to be necessary for what ML applications you are interested in. The concept maps I use are very specific, and they avoid the weak connection problem you mention. (It's worth noting that I develop these as an autodidact, so I don't have to take an entire class to just get a few facts I'm interested in.)

First and foremost, don't bother with Java, it'll be dead in 5 years. (Okay, just kidding, sorta.)

Okay, so jokes aside: what do you want? As in, what do you hope that the world will accomplish before you die? Even if you aren't the one who makes the breakthrough, you still benefit. So, what do you hope that someone, anyone, it could be you, it could be some scientist somewhere else, what do you hope they will do, more than anything else?

You seem to point to things that revolve around life extension, and your thought that current methods aren't going to get it done. So, conceptually, what DO you see getting it done? You mention, effective robots to do experiments, and AI to interpret results, but what does that actually mean? What types of experiments? Why a robot instead of a human? As for AI: what results need to be interpreted? What answers are you hoping to find?

I have found that turning a more analytical eye towards your long-term goals, and changing them from purely conceptual to something more actionable, is a great first step for determining what you want to do with your life.

Can I give a counterexample? I think that way of learning things might help if you only need to apply the higher-level skills as you learned them, but if you need to develop or research those fields yourself, I've found you really do need the background.

As in, I have been bitten on the ass by my own choice not to double-major in mathematics in undergrad, thus resulting in my having to start climbing the towers of continuous probability and statistics/ML, abstract algebra, logic, real analysis, category theory, and topology in and after my MSc.

Another example of what you mention in your first paragraph that I've said before: It's easy to break the world record in any running event. Just run faster than the world record holder did!

It should be fairly obvious that it's not just a case of running faster. A list of necessary conditions for success is not a solution. (Though it can be a good start.)

So, after some cursory thought, naturally the part of the system that gives you the most bang for your buck are the first 4 steps. The last 3 steps are designed to help you improve, which is a much slower process than just learning the basics.

So, now to figure out how to recursively apply the the skill of learning a skill quickly to the skill "learning skills quickly".

As I mentioned in another comment, the difference between this and the "common sense" approach is in what this system does not do.

As for what the 20% of this system that gives you the most bang for your buck? That's a good question. Right now my "safe" answer is that it's dependent on the type of skill you're trying to learn. The trouble is that the common threads among all the skills ("Find the 20% of the skill that yields 80% of the results") doesn't have a lot of practical value. Like telling someone that all they need to do to lose weight is eat less and exercise more.

Let me think about it some more and I'll get back to you.

Also, I'd like to compare your system against common sense reasoning baseline. What do you think are the main differences between your approach and usual approaches to skill learning? What will be the difference in actions?

I'm asking that because that your guide contains quite long a list of recommendations/actions, while many of them are used (probably intuitively/implicitly) by almost any sensible person. Also, some of the recommendations clearly have more impact than others. So, what happens if we apply the Pareto principle to your learning system? Which 20% are the most important? What is at the core of your approach?