@NobbZ You are right. Naming Algebraic Data Types ‘containers’ does not cover all of them, but it seemed like a simple word to use for people who had never heard of them before.
A possibly better alternative, that is still understandable for outsiders, might be Composite Types.
I like your introduction, and it actually hadn’t occured to me before that enumerated types are a kind of ADT as well.
Compared to a Union type:
type MyWellTypedMaybe = ImAString String | ImAnInt Int
This is a specialised version of Either a b, namely Either String Int. In a language like elm, which does not know about classes or interfaces, it makes absolutely sense to use specialised versions.
But for Haskell or Idris or even Elixir + fun_land where you can define some kind of interface around some type like Foldable, Monad and whatnot, it’s much easier for a programmer to have that generic Either a b and reuse its instances.
Personally, I really like some of the pre 0.17 concepts of elm, but the absence of classes/interfaces was a showstopper for me. And now with 0.17 where they are moving away from FRP, I am not sure how this will continue and I will continue my search for some good JS replacement…
Also the thing you are calling union-type here is called sum-type in Haskell, since it can represent as many values as Int + String could. On the opposite we have product-types (type Person = Person String Int) which can represent as many values as String * Int could.
In Elm you could implement Either like:
type Either left right
= Left left
| Right right
Then you could just do Either String Int or whatever. I am actually really big on the lack of classes/interfaces myself, those are often just a poorly made crutch for lack of proper function passing/currying/closures, which Elm has fine.
(EDIT: And I really really like exceptionally really hate a generic Either, I’ve never seen a case where a properly named enum/union type is not better. In the example supplied of Foldable and Monad a Result would be more descriptive as Ok/Error make sense, Left/Right does not. Naming is important.)
Eh not entirely, a union in Elm could also be something like this:
type Msg
= Mdl Material.Msg
| InfoConnect Int
| RoomList_Init Int RoomDefs
| SelectRoom Int
| Room_Connect Int
| Room_Info Int {}
| RoomMsg_Init Int RoomMessages
| RoomMsg_Add Int RoomMessages
| RoomMsg_SyncState Int RoomSyncState
| RoomMsg_SyncJoin Int RoomSyncEvent
| RoomMsg_SyncLeave Int RoomSyncEvent
| ClickUser String
| MsgInput_Change String
| MsgInput_Send
| MsgInput_ToggleMultiline
It is not a sum type, it is a tagged union (in Erlang/Elixir parlance it is a 2-tuple of {:tagname, data}). You can have empty data tags like MsgInput_Send and MsgInput_ToggleMultiline above. You can have types with duplicate data types like ClickUser String and MsgInput_Change String. The identifier after the | is a type name, you can even make things that take that given type instead of the whole union, the things after it up to the next | are the data, if any, that the type holds.
But yeah, classes/interfaces missing are a good thing.
I dont understand of how the genetic Either example you gave for Elm is different from a type constructor in e.g. Haskell. Could you elaborate more?
I completely agree that a bad generalisation is worse than no generalisation, but on the other hand, good generalisation can prevent you a lot of work. The only ‘problem’ I see, is that the more abstract you try to go, the harder it gets to name things well.
It’s not, that’s the point. 
Elm types can take arguments so you can build up more complex types where-ever you need. I’ve even found cases where it is useful to extend types, which in Elm you can do like:
-- Convoluted example just to show off syntax
type alias Pos2 baseType valType
= { baseType
| x : valType
, y : valType
}
type alias Pos3 valType
= Pos2 { z : valType } valType
type alias Pos3Float
= Pos3 Float
-- All of these are equal because I used alias above, alias means unnamed type, purely structural
Pos2 {z : Float} Float
Pos3 Float
Pos3Float
-- This structure would satisfy them all
{ x: 3.14
, y: 4.25
, z: 5.36
}
Which is perfectly fine a sum-type.
type Msg
= Mdl Material.Msg -- as many values as Material.Msg has
| InfoConnect Int -- as many values as Int has
| RoomList_Init Int RoomDefs -- as many values as Int * RoomDefs has
| SelectRoom Int -- as many values as Int has
| Room_Connect Int -- as many values as Int has
| Room_Info Int {} -- as many values as Int * {} has (and {} is HUGE!)
| RoomMsg_Init Int RoomMessages -- as many values as Int * RoomMessages has
| RoomMsg_Add Int RoomMessages -- as many values as Int * RoomMessages has
| RoomMsg_SyncState Int RoomSyncState -- as many values as Int * RoomSyncSte has
| RoomMsg_SyncJoin Int RoomSyncEvent -- as many values as Int * RoomSyncEvent has
| RoomMsg_SyncLeave Int RoomSyncEvent -- as many values as Int * RoomSyncEvent has
| ClickUser String -- as many values as String has
| MsgInput_Change String -- as many values as String has
| MsgInput_Send -- exactly 1 value
| MsgInput_ToggleMultiline -- exactly 1 value
The type Msg itself has as many values as the sum of all tags have.
If something is not a sumtype, it has to be a product type.
NB: Because we can “sum” and “multiply” the cardinality of types (sets) we named it algebraic data types 
This example is merely syntax, and I am not really sure if I like it beeing able to inject additional fields into a type like that… I could go back to ruby and monkey patch there…
And {} is similar to haskells () then? OK, I thought it was like “any record”, similar to map/0-type in Elixir.
Yeah I am just using them as a placeholder until I get later code complete that will use them. I can update them later with the actual type they will need to be and get compilation failures everywhere that currently use it, so it works well for my style.
Edit: Oh, and you are not injecting types there, rather that only works with Records (not unions or anything else), and it makes a ‘new’ record type of your extended type.