Yes, I think the difficult problem is not to design and implement a decent strictly typed language on top of the BEAM/Erlang/OTP but to interface it with the outside world. Outside in the sense of everything else running in the same Erlang node.
There is no safe way to really protect yourself from bad calls and messages being sent to you. You could handle it the Erlang way and let it crash but that assumes you have an infrastructure around which knows what to do when you crash. And generally you only crash small bits. You would then have to be able to structure your language/system in such way so that if (when) something goes down you don’t take it all down. I don’t know how this could be done in such languages.
One serious issue with doing an Elixir 2.0 which is radically changed is backwards compatibility. People tend to get really worked up when their old code doesn’t work. 
Look at the problems with migrating from Python 2 to 3.
LFE can consume Erlang macros and record definitions and transpose those to LFE macros and use them. It works on most macros but some macros just aren’t transformable to lisp macros. It would probably be possible with Elixir macros as well but transforming the Elixir code to LFE is probably more difficult.
One problem I have with the Elixir compiler is that is doesn’t feel very open, for example I don’t know of any well-defined way to get the resultant Elixir code after all macros have been expanded. Yes, there are ways of doing it but not in the same easy way as with the Erlang compile where you just give it an option (‘P’) and out comes a file with the expanded code. This would help a lot when writing macros and when trying to understand other macros.
LFE is already typed in the same way in the same way as Erlang and Elixir so you can run dialyzer on it. And get the same results as running dialyzer on Erlang and Elixir. 
Not surprising as that it why Elixir is implemented on top of BEAM/Erlang/OTP, to get access to all those features more or less for free.
While doing macros on top of Erlang is not really that difficult you have probably insurmountable problem and that is the syntax. Basically the macros transform function calls into other syntactic constructions. The problem is that function calls in Erlang really look like function calls so there is no real way to define new syntax. And parse transforms are about as powerful as you can get seeing you work on the whole module, but you can’t do anything about the syntax.
It is easier in Elixir because even though you are still transforming function calls the syntax is more lax and allows you to write things which are function calls syntactically but don’t look like it. The trivial example is of course def so
def foo(n) do something(n) end
is a call to the macro def of 2 arguments, but it doesn’t look that way.
