Elixir gives you the “i” command out of the box which might help, too:
iex(2)> i "ä"
Term
"ä"
Data type
BitString
Byte size
2
Description
This is a string: a UTF-8 encoded binary. It's printed surrounded by
"double quotes" because all UTF-8 encoded code points in it are printable.
Raw representation
<<195, 164>>
Reference modules
String, :binary
Implemented protocols
Collectable, IEx.Info, Inspect, List.Chars, String.Chars
Why did Erlang use the term “binary” when it had other connotations?
It’s literally the only datastructure in the erlang typesystem that lets you look at binary data under the hood as exactly as it’s represented in memory (ok, that’s a bit of a lie, but let’s not get miss the beautiful forest here for the dark patch of the endianness trees)
These two are not the same - String.split with an empty string splits on graphemes, which are a further unit bigger than codepoints.
The rules for clustering codepoints into graphemes are defined by the Unicode standards, and the code for handling them is generated from canonical text files.
iex(4)> String.codepoints("🇺🇸")
["🇺", "🇸"]
iex(5)> String.split("🇺🇸", "", trim: true)
["🇺🇸"]
iex(6)> "🇺🇸" <><<0>>
<<240, 159, 135, 186, 240, 159, 135, 184, 0>>
The single displayed character 
is a grapheme, composed of two codepoints U+1F1FA and U+1F1F8, represented by 8 bytes.
Another way that codepoints and graphemes can diverge is combining characters; for instance, U+0308 is “Combining Diaresis” which will add ¨ to the preceding character. Example:
iex(9)> s = "ca\u0308t"
"cät"
iex(10)> String.codepoints(s)
["c", "a", "̈", "t"]
iex(11)> String.split(s, "", trim: true)
["c", "ä", "t"]
(note that the combining character prints very oddly when isolated inside ")
FWIW, there is nowhere in the docs with that line. If they were, they would indeed be incorrect.
Other than that, you are right, codepoints are integers. String.codepoints returns codepoints as UTF-8 encoded binaries, i.e. codepoints as strings. The precise definition of this would be “code unit” but we wanted to avoid introducing yet another term. I have updated the docs to make it clear that String.codepoints returns an encoded representation, not integers. Thanks.
I apologize, I paraphrased what was running through my head slightly inaccurately (since codepoint numbers don’t exactly go to bytes exactly as one might expect). The first line in the documentation says:
Strings in Elixir are UTF-8 encoded binaries.
Just wanted to make sure that that is, indeed correct.
This is a great example – very educational.
How can you match on the \u0308t? The following results in a match error:
<<x::utf8>> = "\u0308t"
But String.valid?/1 and String.printable?/2 both return true.
Are there other unicode characters that cannot be matched? And how can we deal with parsing them?
You are matching on a binary that has a length of a single codepoint, though "\0308t" has a length of 2 codepoints. The trailing t is meant as this, a literal t in the string, its not part of the \u escape sequence 
Do you feel it would make sense to have an option for String.codepoints/1 so it could return integers (or hex representations)? Part of the confusion for me is having this function that doesn’t exactly return what its name would suggest. We say “codepoints are integers”, and then we immediately equivocate them with UTF-8 encoded binaries – it’s no wonder this confuses so many people.
Something like the following would make a bit more sense to me, I think it would better communicate what’s going on:
iex> String.codepoints("cat", as: :binaries)
["c", "a", "t"]
iex> String.codepoints("cat", as: :integers)
[99, 97, 116]
iex> String.codepoints("cat", as: :hex)
["0063", "0061", "0074"]