There is no reason to define variants (besides being wrong to begin with, in this case):
\tl_if_eq:NNTF \l_tmpa_tl \l_tmpb_tl {true} {false}
is already the thing to do (and yields false in your case).
You might think to do a comparison between an explicit token list and (the contents of) a token list variable, defining variants of \tl_if_eq:nnTF.
You can do
\prg_generate_conditional_variant:Nnn \tl_if_eq:nn {Vn,nV} { T,F,TF }
and now something like
\tl_if_eq:nVTF {abc} \l_tmpb_tl {true} {false}
\tl_if_eq:VnTF \l_tmpa_tl {abc} {true} {false}
will work (in your case the former yields false, the latter yields true).
The function \prg_generate_conditional_variant:Nnn is a wrapper around \cs_generate_variant:Nn that's meant to define variants for conditional functions (signature ending in TF, T or F); it avoids having to apply several times the basic function.
With the code above you define all variants
\tl_if_eq:nVTF
\tl_if_eq:nVT
\tl_if_eq:nVF
\tl_if_eq:VnTF
\tl_if_eq:VnT
\tl_if_eq:VnF
at once. Note that defining \tl_if_eq:VVTF is useless, because it would be the same as \tl_if_eq:NNTF, just slower and not fully expandable.
abc, and the other is a stringabc. – Phelype Oleinik Oct 22 '19 at 11:15