Here's the issue in action.

fossil sql
SQLite version 3.32.1 2020-05-25 16:19:56
Enter ".help" for usage hints.
sqlite> select * from vfile;
1,12,0,0,0,0,8,8,1587129377,'one.txt',NULL,NULL
2,12,0,0,0,0,11,11,1587401372,'three.txt',NULL,NULL
3,12,0,0,0,0,4,4,1587400832,'two.txt',NULL,NULL
sqlite> .separator |
sqlite> select * from vfile;
1,12,0,0,0,0,8,8,1587129377,'one.txt',NULL,NULL
2,12,0,0,0,0,11,11,1587401372,'three.txt',NULL,NULL
3,12,0,0,0,0,4,4,1587400832,'two.txt',NULL,NULL

fossil version
This is fossil version 2.11 [4df919803b] 2020-05-25 23:23:49 UTC

When using sqlite3 client to access the Fossil repo db-file, the .separator setting is respected properly.

In addition to setting the column separator, you need to set the output mode.

For example,

> fossil sql
SQLite version 3.32.1 2020-05-25 16:19:56
Enter ".help" for usage hints.
sqlite> .mode list
sqlite> .separator |
sqlite> select * from localdb.vfile limit 3;
1|73|0|0|0|0|64|64|1587450659|Makefile.msc||
2|73|1|0|0|0|71|71|1587665537|shell.c||
3|73|0|0|0|0|9|9|1586463408|sqlar.c||
sqlite>

Thanks!

Just for completeness, looks like with "fossil sql" the default mode is "quote".

fossil sql
SQLite version 3.32.1 2020-05-25 16:19:56
Enter ".help" for usage hints.
sqlite> .mode
current output mode: quote

sqlite> .help .mode
...
     quote    Escape answers as for SQL

What does this mean?

See section 5 of "Command Line Shell For SQLite".

Quoting from the doc link:

In "quote" mode... All columns are separated from each other by a comma (or whatever alternative character is selected using ".separator").

I guess, this may point to a SQLite bug. Clearly, the .separator setting is ignored in quote mode and defaults to comma.

with section 5's verbiage considered, it appears that quote mode is for producing sequences of literals such as might appear in a SQL VALUES clause.

Is it so actually? It does not seem forthcoming from the description. I see how this could be used in VALUES clause, but this describes just output value formatting, not the output sequencr formatting, as it may be heterogenous as well, mixing data-types.

I believe so. The code uses a switch to emit literals according to the type of the value being output: single-quoted text, '0x'-prefixed hex for blobs, unquoted numeric output for integers and reals, and NULL for nulls. This output, if comma-separated, is precisely what would appear in a VALUES(...) clause to load the same values in an insert statement.

True, this does not seem to be made plain in the documentation or .help output.

It seems that while the topic is discused, drh is working on fix, Enhance the ".quote" mode in the shell so that it honors .separator..