TCL is exactly "strongly homoiconic" in the OP's sense; one does metaprogramming by creating and evaluating strings in some desired context. It's an advanced technique, but works quite well in practice. Many years ago I wrote a complete object system for TCL, SNIT, that executes a type definition script (using TCL syntax); this produces a new TCL script that actually implements the type; and then executes this new script. It's been used in commercial products.
TCL is not "bicameral" in the OP's sense, but that doesn't seem to stop anyone from doing metaprogramming.
I would argue that Tcl is almost "bicameral" in the OP's sense. The application of the "dodekalogue" rules - https://wiki.tcl-lang.org/page/Dodekalogue - largely corresponds to the "Reader". It goes further in that it also specifies substitution and evaluation rules, but it is similar in that it only applies a few basic structural rules, and knows nothing about the specifics of individual commands.
Tcl's equivalent of the "Parser" is built-in to each command, which decides whether to interpret its arguments as data, code, option flags, etc..
I suspect this division of responsibilities is very helpful for metaprogramming techniques.
This is true. In Lisp terms every TCL command is effectively a special form, and can do whatever it pleases with its arguments.
On the other hand, TCL provides much less support for building up the string to be evaluated if it's more complex than a single command; and even for a single command it can be tricky.
TCL is not "bicameral" in the OP's sense, but that doesn't seem to stop anyone from doing metaprogramming.