Oh how I hate branch cuts. This is a problem with branch cuts. Anytime you see inverse trig/hyperbolic trig functions and something unintuitive, you can bet that it's something to do with branch cuts. 

To begin, let's compare your answer and Mathematica's answer:

To simplify things, let's factor a Sqrt/Sqrt[2] out of both of these:

We now want to see if there's a constant value of C[1] such that these are equal.  Let's use Solve to see what this might be:
The result is:

ArcTanh[Coth] is a complicated thing, but it's basically equal to either x+I Pi/2 or x-I Pi/2 depending on what your needs are. You or the computer have to choose the right branch of the function to take. With either of those values though C[1] is a complex constant. 

So... Mathematica's solution does include your solution if you choose a complex value for C[1] and somehow manage to take the branch cuts correctly in calculating the result. I hope this kinda explains what DSolve is likely thinking. Humans tend to be very good at guessing what the correct branch to take based on what they know an equation to mean or how it will be applied. This isn't the case with computers of course so it becomes a problem. 

Both,
And 
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:
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
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:

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.