Creating a join index results in a JI subtable creation. The concept is similar to how Secondary index creation results in a SI subtable creation. Whenever the data subtable is updated, any updates that should get reflected in the Join index / Secondary index subtable is also applied atomically by the Database.
The load utilities (multiload and fastload) were simply not designed to maintain join indexes. The load utilities don't support a number of newer features (e.g., triggers, LOBs, RI). For tables that use those features, data can be loaded first into a temporary staging table, then transfered in bulk using standard SQL statements, such as INSERT or MERGE.
One of the critical working intrinsics of both Multi Load and Fast load are that they are AMP local. That's One good reason for not supporting JI...
But yes you can have a single Table JI with same PI, which would be AMP local, so it doesn't answer the question why mload won't support one of that kind. My guess would be that a single table JI with same PI could be mimicked by an NUSI for most part. (which is supported my mload)
As far as Fastload not supporting anything ... well who would want indexes on an empty table anyway ;-) ... probably instead of internally recreating all the indexes at the end of a load, they just shoved it off to the App dev guys. :o
Once mload get's into the APPLY phase, ie., when it begins to apply the input records onto the target table, the worktable contents of an AMP reflects the records that should go into the target table on the same AMP (ie there's no more rehashing into a different AMP). Also this is the reason why mload doesn't support USIs but supports NUSIs.. NUSIs are AMP-local. where as USI subtable contents are hash distributed. This means that to build the NUSI subtable of the target table, an AMP needs to work only on it's copy of the NUSI subtable. where as for an USI it would have had to talk to other AMPS. And talking to other AMPs are always a costly (if not expensive) affair over the bynet.