I find reading the docs is the best way to truly understand a language. Reading other tutorials, books or starter manuals kind of gives you a tour of the most popular parts of the language and you have to piece them together yourself (although a good book may explain it in a more friendly way).
Perhaps it comes with experience. My first few languages were learned ad-hoc like most people learn. Only after experience with a few languages did I start reading the manuals and getting an even better understanding of them. You learn a lot even when you previously thought you were already fluent with a particular language.
I find it really helps to write a parser for the language (Assuming the language can be parsed with a LL/LALR Grammar or PEG). It doesn't need to be a robust parser which handles all errors, but just a trivial one which can help you to understand all of the edge-cases in the syntax. A parser you wrote yourself makes a good reference. Depending on the complexity of the language this can take a few hours to a few days to write.
Once you have mastered the syntax, begin to tackle the standard/common libraries bit by bit. Try to write small but useful applications to utilize particular parts of libraries. Name them well so they're easy to refer to again later, so when you come to need a particular library feature you can look up how you done it last time. (Although you'll usually look at these and be like "What the hell was I thinking back then?")
So if I were to be learning Swift, I'd grab the ePub from here: https://swift.org/documentation/#the-swift-programming-langu... and skip directly to page 917 which lists the language's context-free grammar. This is essentially a 42 page cheatsheet for the entire language syntax (could probably be condensed to about 15 pages if split into two columns and whitespace removed). This epub is a great example of well-written documentation. It's broken into groups of production rules with good cohesion, and every terminal and non-terminal symbol in the grammar is hyperlinked to the part of the document which describes it in more detail.
I'd read through the grammar and perhaps even rewrite it side-by-side as I'm going through it. (There are some good tools for writing and testing grammars interactively, which I would definitely make use of). I'd guess since the language borrows from C#, Java, Haskell et al, which I'm already familiar with, that I'll be able to understand the majority of it without looking up details - but when i do encounter something I'm not sure of it's just a click away.