Has Xiangqi been solved?
Not even close, by a very, very, very wide margin.
The large endgame tablebase material combinations built by Xiangqi software enthusiasts so far include, for example, Chariot and Cannon vs Horse, Cannon and full Advisors and Elephants (four major pieces plus two Advisors and two Elephants), two Horses and one Elephant vs Horse and Pawn and two Elephants (three major pieces plus one Pawn plus three Elephants), two Cannons and one Advisor and Elephant vs Horse without Advisors (three major pieces plus two Advisors plus three Elephants), two Horses and Cannon and one Advisor vs Chariot and two Advisors (four major pieces plus three Advisors), and Cannon and Pawn with a single missing Elephant vs Cannon and Pawn (two major pieces plus two Pawns plus two Advisors plus one Elephant). This shows how extremely far we are from "solving" the game (twelve major pieces plus ten Pawns plus four Advisors plus four Elephants).
Of course, because of the nature of Xiangqi itself, the draw rate between strong engines is already extremely high (for draw rates, see What is the draw rate of top Xiangqi engines?), but that does not mean the game is solved.
The most accurate estimate of the total number of Xiangqi states so far is the paper "Dynamic programming to calculate the total number of Chinese chess states" (《动态规划求解中国象棋状态总数》) published in the Chinese Association for Artificial Intelligence's journal CAAI Transactions on Intelligent Systems. The author also published it on Zhihu: Total number of Chinese chess states. Despite some small issues, it is safe to say the order of magnitude is around 40 digits, or, conservatively, close to 40 digits. Even the theoretical minimum storage would need nearly 30 digits of TB, while the total amount of data worldwide probably does not reach 14 digits of TB. As for computation, without storage you would only produce a huge amount of repeated calculation. Even if we ignore storage entirely and compute each position only once, a dual-socket EPYC 9654 running the 2023 version of Pikafish at full load calculates about 300 million positions per second in the opening. Since Pikafish slows down from using neural network evaluation, suppose a minimal evaluation reaches 1 billion positions per second, and suppose the whole world had 100 billion dual-socket 9654 machines. Running for a hundred years would still only reach the order of 30 digits, which is still far too little.
Floating-point computation has nothing to do with Xiangqi, and quantum computers so far only solve specific problems (and the special cases usually cited actually show they can solve very few problems). There is no sign yet that they could solve Xiangqi.
There is also the claim that "Xiangqi has a limited number of reasonable moves, so it can basically be exhausted". The problem is that whether a move is "reasonable" has to be backed by exhaustive results. There is no way to know whether a given move is unreasonable. Today's strong engines already prune a great deal, and the purpose of pruning is precisely to search only "reasonable moves", yet there are always many positions in which engines have difficulty finding the best line.
Even with today's engines, positions with serious evaluation misjudgments are occasionally found. It is reasonable to infer that there are quite a few serious misjudgments not yet found; they are just hard for both sides to reach in normal balanced games (Xiangqi has a high error tolerance).
Positions with low error tolerance show very well how software misjudges. One example is engine performance in unbalanced (high-advantage) openings. In a high-advantage opening with a 50% draw rate, even self-play between the strongest machines can produce cases where "this time the position leads to a Red win, but next time it leads to a draw". Sometimes the engine evaluates its side as hugely ahead yet the game still ends in a draw, and sometimes it evaluates its side as only slightly ahead yet still wins. Such examples are everywhere, and they show intuitively that today's Xiangqi engines are far from "godlike".
