1) Jobs always terminate, assuming they start. They may finish gracefully, or be user aborted, but they will run to completion. The only major issue is if they never start, which is pretty much limited to trying to update more than 50,000,000 records in a single batch. You do need to be aware of governor exceptions though. This can cause a batch of 200 records to fail to update while the rest of them update correctly. You will not be able to ever have a scenario where a user is editing a contact that is part of the batch, because one of three conditions will happen: (a) the user will be told to reload because their view is inconsistent with the database data, or (b) the user's work will be sideswiped by the batch process (potentially), or (c) the batch process would step over that record and get to it next time (as in, 24 hours later, for example). It depends on exact;y when the edit occurs.

2) There's no point in running a second batch, because in the (rare) condition that a record is missed, it will be updated on the next pass anyways. You might choose to use a date field to identify when the last successful update on the record happened through a batch process, perhaps, but that's really about all you'd want to do. Batches are transactionally isolated from all other edits, so you can even run the batch at noon if you wanted to with very little mishap (see 1). Obviously, not disrupting the user base is why most jobs are run late at night, but the choice is yours.