Field 2 should be an email address but can contain any junk including
unescaped newlines and colons. This has to be taken into account when
parsing the data.

Field 3 is either an user id identical to field 1 or an username.

Field 4 is a sha1 hash of the password. The password was converted to
lowercase and truncated to 10 characters before hashing.

Field 5 is a salted sha1 hash of the password. The salt is the user
id in field 1. Unlike field 4 the password doesn't appear to have been lowercased and truncated
before hashing.

Counting hashes
Each record that has a hash in field 5 also has a hash in field 4 but
the converse is not true. Some records have no hashes at all. In total
359006286 records have an associated password.

Recovering salted passwords
The password in field 4 is a truncated and lowercased version of the
password in field 5. One can use the truncated password in field 4 to
recover the full password in field 5. If the password is shorter than
10 characters this is trivial.

That were some really good ideas you discovered there, as soon as I saw your post, we (CynoSure Prime) tried to use this information to recover the real passwords for the hashes where this is possible.
There is a more detailed text here: http://cynosureprime.blogspot.ch/2016/0 ... eyond.html

About your question, if the hashes get added to Hashes.org:
Currently the list is just too big to be handled well by the database and storage space is limited for this. And also as the passes from the non-salted hashes are not 'real' password as they are lowercased and cut by length 10, there could be better hashlists to have imported I think.