But dialyzer has a type system
Sure, but only if we stretch the definition into uselessness. If we look at dialyzer through the lens of it having a type system, values are lifted to the type level which more or less turns everything into a tautology:
“The type of 1 is 1, the type of :foo is :foo.”
“The return type of bar(1234) is the result of bar(1234).”
“The argument types for quux/2 are those for which it produces a value.”
The latter has funny implications for server loops and other code that doesn’t return normally by design. Oh, and as the type of a value is its value, doesn’t that imply that nearly all functions have dependent types? After all, 1 + 2 returns 3 and that’s a type all of its own 
Understanding that dialyzer only reasons about sets of possible values is crucial to working with it.
For example, if Erlang/Elixir was a statically typed language, maps there would be dependent. When their size is less than 33 items, they use
flatmapimplementation, while for bigger sizes they usehashmapimplementation. So, in this example the type depends on the size of the map
That detail is hidden and could still be under a dependent type system, perhaps a better example would be list_to_tuple/1 where the arity of the tuple depends of the length of the provided list.
How so? How could I make this work?
By teaching dialyzer that all numbers can have ranges, not just integers. It should be about as simple as making the integer range logic in lib/dialyzer/erl_types.erl allow any kind of number as lower and upper bound and change all uses to match that. That’s what we do in the Erlang compiler (which has a separate implementation of dialyzers underlying algorithm) and it works just fine.
