A separate control character was not needed to indicate where your Hollerith string ended: it ended at the end of the Hollerith string. If you wanted to render a Hollerith string onto print media, you'd often want to feed the line and then return the carriage before printing the next Hollerith string. Of course, that wasn't strictly necessary if you were using a line printer, which would just print the line and advance.
The filesystems I used had 5 kinds of file: random-access, sequential, ISAM, Fortran-carriage-control and carriage-return-carriage-control. The only people who used the latter were the eggheads that used that new-fangled C programming language brought over from Bell Lab's experimental Unix system.
You're probably just looking for the record separator (036). If you are storing multiple text records and a block of memory, that would be the ideal ASCII code to separate them.
Fortunately unfruitful, since if it had gained adoption, there'd be a mix of three different line endings (and combinations thereof) in widespread use, instead of two.
I'm not sure I'm following. We have had multiple line endings (based on combinations of two particular characters) in common use, without consolidating to a common standard, for decades -- why would introducing a third character have made that more likely?
Because the reason consolidation has not happened is simple: There's no right answer, as there's no code explicitly defined by ASCII for ending a line. A major oversight.
If a code had been timely assigned, we'd have the correct way (predominant), and the legacy ways (mostly gone by now).
CR and LF aren't dedicated, and have precise cursor movement meanings, rather than being a logical line ender.
There was a proposal in the 80s to reassigning the -otherwise useless- VT (vertical tab) character for the purpose. Unfortunately unfruitful.