Your question is unclear. But you seem to be asking the following of that query Q0: When a row of T1 matches multiple/duplicate rows of T2 will using COUNT equality filter it out of the result and so not give the right answer?
If there are no duplicates of the row in T1 [sic] then yes it will be filtered out. (Otherwise it might or might not be.) But there are no duplicate rows in relational algebra, so this is all moot.
For a version handling duplicates in SQL you have to decide what you want "divide by" to mean when there are duplicate rows. You can reuse an algebra definition while taking the names of other algebra operators to be similarly named SQL/bag operators, but you get different results depending on what definition you start with.
Anyway Q0 does not return a division. Division can return rows of T1 whose B does not appear in T2; Q0 cannot. Division returns rows AB of T1 where A appears in T1 with every row of T2 and some row of T2. Q0 returns rows AB of T1 where A appears in T1 with every row of T2 and only rows of T2.
In fact relational division, Q0 and Q1 ask for three different sets of rows. Q1 returns rows AB of T1 where A appears in T1 with every row of T2.
The paper is poorly written:
Q0 does not calculate relational division.
The paper calls query Q1 the "classical version" of division but Q1 is not division. (The paper acknowledges this via "the code for Q0 and Q1 produce two different results" yet contradicts itself by calling Q1 an "implementation of the division operator" and Q0 "an alternative implementation".)
PS: SELECT removes duplicates if and only if DISTINCT is specified. IN tells you whether a row is in a table. Asking whether a row is IN the DISTINCT version is always the same as asking whether it is in the non-DISTINCT version. Assuming that we want rows WHERE subrows are IN a subselect, there's no need to use DISTINCT.