Both,
(Sqrt[c] Coth[Sqrt[2] Sqrt[c] t + Sqrt[2] Sqrt[c] C[1]])/Sqrt[2]
And
(Sqrt[c]*Tanh[Sqrt[2]*Sqrt[c]*t + Sqrt[2]*Sqrt[c]*C[1]])/Sqrt[2]
Are sets of solutions parameterized by a constant. The question is whether they parameterize the same set of functions. They essentially seem to do that.
Replacing C[1] with FirstEquationsConstant and C[2] with SecondEquationsConstant, we can see if there's a straightforward relationship between them:
Solve[(Sqrt[c]*
Tanh[Sqrt[2]*Sqrt[c]*t +
Sqrt[2]*Sqrt[c]*FirstEquationsConstant])/
Sqrt[2] == (Sqrt[c] Coth[
Sqrt[2] Sqrt[c] t + Sqrt[2] Sqrt[c] SecondEquationsConstant])/
Sqrt[2], SecondEquationsConstant]
If we again say that ArcTanh[Coth] or ArcCoth[Tanh] is x + I Pi/2, or x - I Pi/2 or another valid branch cut we get the following relation
secondEquationsConstant = FirstEquationsConstant + (I \[Pi] (1 + 2 C[1]))/(2 Sqrt[2] Sqrt[c])
Where C[1] here is another constant caused by a branch cut that can take an integer value.
So I'm not sure it's really a bug as much as the pain and suffering brought to us by complex branch cuts.
It's best to have some kind of context for how "Smart" a solver can be with branch cuts. Consider this DSolve statement:
DSolve[Sqrt[D[f[x], x]] == -x, f[x], x]
The result it gives is x^3/3 + C[1]. Is this correct? It doesn't even solve the original equation unless we manage to take the right branch cuts, which aren't the principal ones. Then again it's also the result we'd see from NDSolve or a numeric solver.
If you ever believe you have found an issue, forward it to support@wolfram.com along with your activation key or license number. They can in many circumstances state whether something is an issue or just unexpected. Otherwise, they can make sure a developer looks into the issue for a future release. But it's also very possible when working with inverse trig functions that the problem you are seeing isn't exactly a problem with the solver, but something bigger. It can take a lot of effort to determine which is which sometimes.