It is. There's a fairly simple construction compiling from CT to CT2.
First, consider that it's possible to double every command in a CT program without producing any behaviour (that is, A
becomes AA
, B
becomes BB
, C
becomes CC
). The queue of bits now has every bit doubled, but the cycle of commands only does anything with every second bit, so the modified behaviour has the same behaviour as the original.
Let $n$ be the number of A
commands in a program. You can observe that pushing a string of $n$ false bits (indeed, any multiple of $n$) will have no effect on a CT program (as will not pushing a string of $n$ false bits), so you can safely write a string of $n$ B
s anywhere in a program without changing its behaviour.
Suppose we take a CT program with every command doubled, and insert a string of $2n$ B
s immediately before each AA
pair (i.e. immediately before an A
before it was doubled); here, $n$ is the number of A
commands after the doubling (i.e. twice the number of A
commands in the original program). This does not change the behaviour of the program. Additionally, those B
s that happen to be in even positions can be changed to C
s without changing the behaviour of the program (because the even-numbered bits in the queue are skipped by the second A
command of a pair, their values are irrelevant). We can thus change somewhere from $0$ to $n$ of each run of $2n$ inserted B
s into C
s, and produce a CT program which has identical behaviour to the original, and for which additionally the number of B
s between each pair of A
s is a multiple of $n$.
Now consider what happens if we reinterpret this CT program as a CT2 program. It will have mostly the same behaviour as the CT program, except that sometimes an additional run of a multiple of $n$ false bits will be appended to the queue (due to B
commands running when the head of the queue is false). The added bits will always be in runs whose length is a multiple of $n$.
When these runs reach the front of the queue, they will, in effect, end up pushing a number of false bits onto the queue equal to the number of B
commands in the entire program (rather than doing nothing, like they would in CT); this happens regardless of where the false bits appear in the queue and regardless of what point of the program we have reached (they cycle through the program from some point in it back to that point again). But this is still going to be a multiple of $n$ (the number of B
commands between any two A
commands is a multiple of $n$, so the total number of B
commands is produced by adding multiples of $n$ and is still a multiple of $n$).
In other words, there's a direct correspondence between CT programs constructed as above (which have the same computational power as CT programs in general), and their reinterpretations as CT2 programs. If you define CT2's halt state as "the queue consists entirely of false bits", this is sufficient to make CT2 Turing-complete. (I don't know whether it's possible for nontrivial CT2 programs to halt if you continue to define the halt condition as the queue being empty, though.)
(As a side note: is this question just a question-in-the-abstract asked out of curiosity, or do you need it as an intermediate result for something? I've been looking at similar but more complex constructions when trying to produce Turing-completeness results for various simple languages, and if you're aiming to do something similar yourself, I'd be interested to know what you're working on.)