All passwords are salted with the same salt.
Duplicate / reused passwords will show up because the resulting password hash is identical. Cracking the password database will become easier as all the passwords can be cracked at once using a specialized rainbow table or simple comparison against all the passwords in the database.
An attacker could also setup a website with the same salt and hope that users will repeat their passwords; in that case duplicates will show up even if the username is different.
There is still one advantage left for the salt: hacking multiple databases at the same time using rainbow tables or dictionary attacks is still thwarted (unless the salt is reused, e.g. when using
"007" as salt, and other implementations do so as well).
The application does not use salting, but end users choose their passwords by appending to them a (random) salt. We make the assumptions that these users are able to remember them, and that an adversary has access to both the identities of users and the salts that have been used in the associated passwords.
That depends on the quality of the salt; but given that the users should remember them they might as well use a longer, unique password. Because they are going to forget that salt, especially if it is specified as e.g. hexadecimals.
Using a unique (hash over a) username as salt is possible, but that means that the password must be refreshed if the username is ever taken; repetition of the password by the same user may show up. You should add a static "pepper" - a secret constant salt - to this kind of salt to make it unique for your specific database.