I would strongly urge a doctor who gets sick to either use a pseudonym or go to some other hospital at which he's not listed as a doctor. MUMPS code and its schemaless shared-everything database (for medical records!) is terrifying enough all by itself before you give it edge cases like "this doctor is a patient".
No, that would not be a good thing to support. There can be Doctors and Patients that refer to the same real person, but you don't normalize these entities with respect to a single Person column. It's just not worth it, because you too rarely care that a Doctor can also be a Patient. In such a case, if it poses a problem (only when Patient is assigned himself as Doctor?), it will sort itself out in The Real World.
True, this example of doctors and patients is just the wrong sort of example, because that world has already been standardized into oblivion. However, in general, for your relatively small app for company X, you wouldn't go this far. In general, the fact that a supplier can sometimes also be a client is usually not very interesting.
Interesting question, but does it really matter? You're not tracking persons in general like a government would do, you're only tracking staff and clients. It would matter that a doctor is also a patient only if he/she would have some kind of preferential treatment, e.g. a discount or a better room.
No, simply because they are from different domains and by extension from and for different systems. And as such, a natural ID (or arguably a GUID) can also be said to be more fitting to establish that kind of relation.
