Both outcomes are valid; your expectation of a particular result is wrong. t1.X is a bare column in an aggregate query (a column that appears neither in an aggregate function call, nor in a GROUP BY clause). Therefore, this applies:

If the aggregate is composed from one or more input rows, then a bare column will take on the value of an arbitrary row from the aggregate's input. The particular row chosen might change from one invocation to the the next. If the aggregate is empty (if the aggregate has no input rows, as happens if no rows match the WHERE clause), then the bare column can take on any arbitrary value, including values that are not found anywhere in the tables of the FROM clause.

Your example falls into "aggregate is empty" case. t1.X can have any value whatsoever, including but not limited to NULL.

Thank you for your correction and detailed explanation!
I will keep learning and study the SQLite documentation more carefully.

Here is an example.

CREATE TABLE t1(a INT, b TEXT);
INSERT INTO t1 VALUES(1, 'A'), (2, 'B'), (3, 'B');
CREATE INDEX idx_partial ON t1(a) WHERE b = 'B';
SELECT * FROM t1 WHERE a IN (1, 2) AND b = 'B';

Expected：(2, 'B')
Result：Null

I wonder if this is a bug.

That would be a bug, if I could get it to happen. I tried your script on the latest trunk check-in and on every historical version of SQLite that I have readily at hand, and they all got the correct answer, though. So I don't know how you are getting a empty result. Maybe give us more detail about what you are doing?

https://sqlite.org/fiddle/

Produces 2, B

for your code.

It's certainly worth ensuring that such "bugs" you may discover reproduce on this version of SQLite, as a minimum.

I tested it in an earlier version,it has been fixed now.