Looks pretty good. I think one wouldn't want to have both rectangular and polar representations at the same time, honestly. What you really want is to be able to pick one or the other by changing an import (on its way) and trying the same code both ways. For some algorithms, the polar representation is going to be more efficient.
Also, the Complex128 and Complex64 types are a nasty hack to get C-struct-like layout using a bits type. What you really here is to have both rectangular and polar complex representations be immutable composites (also a planned feature) so that they can be automatically represented in a way that's compatible with C structs. Until that happens, composite types can't hope to compete because they don't have a sufficiently compact layout and force extra pointer dereferences and heap memory lookups.
Until those features happen (modules and immutable composites), I wouldn't worry too much about performance, but just work on making polar complex numbers a drop-in replacement for rectangular complex numbers to the extent possible.