Can you elaborate on this? I am on Arch with systemd, typing in a bash cl, and tried exactly your "jou (TAB) -F (TAB)" example. Just as I expected would happen, the first tab filled in "rnalctl ". So far so good. Every arbitrary command has done this for years. And, just as I expected would happen, the second tab did nothing until I repeated it a second time, and then offered me a list of every file and every directory in the current directory. A useless list, as a filename is not appropriate as an arguent to the -F option to journalctl. How could it do anything else? Are you suggesting you can make it offer a lift of fields appropriate to the -F option?
Oh, you miss one of the great joys of journalctl. Get the "bash-completion" package and try again. Basically every field, record and their values is tab-able.
try "journalctl (TAB)" and it will show you some field names like _PID, _EXE etc.
You can tab all the way in these examples:
journalctl _EXE=/usr/bin/umount (shows what umount has written in the log)
journalctl _TRANSPORT=stdout (journald captures all stdout, so this shows all log entries generated this way)
journalctl _KERNEL_SUBSYSTEM=usb (shows all usb messages generated by the kernel)
journalctl _MACHINE_ID=5644ac089b164945bfdc47a77f74324d (every machine has UUID, since hostname and what not changes. This is mostly useful when when working with multiple computer logs at the same time. The point is, that even with +100 computers in the loq file, it only requires a single tab after the "=" to show each and every one. And you may only need to key in the first digit or two, before you can use tab to complete the entire UUID.
Of course there is also full tab support for all switches
Try "journalctl --(TAB)"
And because it is a db file, it can also get corrupted. And a corrupted db is almost impossible to extract anything useful from. A corrupted text file, which is only appended and never positioned ahead of EOF, can be read perfectly up to the point of corruption, and with some work can be read after the end of the corrupted section too.
All that aside, I grant the pluses of the journal, and as long as I can run syslog in parallel, I guess I don't have any sunstantial issues. It should never be mandatory to have the journal though.
Sure db's may get corrupted, but are useful too, or otherwise we would all use flat file text databases for everything.
Anyway, the journald log files isn't a pure db, it just feels like it because it is structured and indexed. Here is what it says on the label:
"The systemd journal stores log data in a binary format with several features:
Fully indexed by all fields
Can store binary data, up to 2^64-1 in size
Primarily append-based, hence robust to corruption
Support for in-line compression
Support for in-line Forward Secure Sealing"
So it appears to work exactly the same way as you describe text log files, with its append based approach.
Corruption in syslog text files happens all the time. The process may be killed in mid write, a hard shutdown may truncate a message etc. But it is extremely hard to verify loosely structured text files. journald OTOH have internal verification: "journalctl --verify" (don't drop your pants when it shows corruption, it just shows those dead writes you never notice in the text log)
While journalctl have some ability to read corrupted fields, there is still room for improvement according to Lennart Poettering with the exact problem of reading after the corrupted place, so they are working on being able to salvage as much information as possible from a corrupted entry/file, no matter where the corruption occurs.
I can only recommend to spend some hours going through the documentation and examples on this site:
Examples on how to use journaltctl
Description of some field values:
About the journal file format: