Yes, this is a bug in solve (new in Maple 2020, but absent in Maple 2019 it seems). I shall submit a bug report.
The error appears when solve is called under assuming with the assumption on both _C1 and x. It seems to be related to the leading underscore on name _C1.
You can get around the reported error by doing it in two steps, eg.
A := -ln(u)/2 + ln(3*u - 2)/6:
B := _C1 + ln(x):
temp := A-B=0 assuming x::real, u::real, _C1::real:
But there is something else strange and new going on for this example, even without assumptions or assuming. In Maple 2020.1, depending on the particular choice of names for the two parameters (ie. not the solved variable u) the result when passing solve the explicit option may be in terms of either explicit radicals or involve an implicit RootOf. In Maple 2019.2 passing the explicit option produced a result in terms of explicit radicals for this example, regardless of choice of names.
A reasonable guess is that this additional issue might be related to the lexicographic ordering of the three names in play. But it seems more complicated that that. See attached:
Moreover, Maple 2019.2 produces the result with explicit radicals for your example even when solve is not passed the explicit option. So, if you are wanting the same explicit radical kind of solution as Maple 2019.2 produced then you might need to utilize allvalues in Maple 2020, since this additional issue isn't necessarily avoided by removing the leading underscore on the name.