As with the title, are they usually developed together in a custom engine, or are they mostly developed independantly of each other? e.g. the server and client as completely different projects that would just share the engine as a DLL or something?
It's fair to say that for the sort of authoritative server / pure client which nearly all MMORPGs use for unavoidable security reasons, the server is typically developed with the specific purpose of serving that specific data which the client engine needs to consume in order to function.
This works much the same for highly visual business applications, which at some point early in development, if not right at the start, split out the business logic and develop that as the backend. This development process tends to be highly parallel with much ongoing feedback between client & server devs (can occur rapidly early on, if the same dev works on both). You can generally rest assured that though there may be shared components, the two projects will be kept as distinct source repositories, at the very least. Git submodules are often used for shared components.
Besides security concerns, remember that games are quite complex both design-wise and technically, and are usually on tight development budgets; we generally do not have the resource to make a server so generalised that it could be used with multiple clients; highly generalised code penalises us in terms of code comprehension (thus maintainability) and performance. It's a rare case to see multiple front-ends / clients for the same server.
(Dwarf Fortress is one such case, probably this was possible because the vast majority of its code was anyway non-rendering code, since its base renderer is very simple, the process of separating that out was probably fairly trivial and could have been done quite late into the project's lifetime).
This is too context-dependent.
Some MMORPG games that I had a chance to look at in terms of source code preferred to develop the server and the client as separate codebases. Some of them didn't even share any code between the two. If it was a custom engine I too would probably prefer them to be separate.
But if you are using an already established game engine for your client (such as Unity or Unreal), you might as well use the engine in headless mode for your server too, just for the sake of development speed.
The answer is, it depends. My MMO is a separate development stack. My client is developed in Unity, and my server is .NET so they necessarily must be developed separately.
However, Unity for example allows for developing server code and client code right alongside each other. When you are done you end up compiling both the client and the server, OR each instance is both client and server and you tell it which it is.
Warning: Sweeping generalizations will be made here.
Client and server development (for the most part) is written in languages suitable to the task. The client will (most likely) be C++, C#, or mobile native. The server will again most likely be written in a "web-friendly" language. You will not write your server in C++ when Java, Python, Ruby, Go, Node, C#(?) are available and come with lots of APIs for web/cloud services like load balancers, databases, API gateways, serverless functions.
The important part is that the server and client are doing very different jobs. They have particular anxieties. You can always throw more or larger hardware at a server problem - very hard to do that on the client!
You can share (note: can and not will) the DTO's (Data Transfer Objects). This is incredibly natural if you are using the same language on the front and backend. This is what I do with C# and Unity and C# with NancyFX on the server. Both share a single classlib containing all our DTO's.
But again, I've seen just as many folks write their own DTO's in Java while the client folks write theirs in Swift or Kotlin.
I've also seen generators where you write the DTO's once in your own DSL, and your own tool/preprocess-step generates the DTO in the correct language for client and server.
There is no "right way" because every situation is different. Maybe you just can't hire any C# backend developers, and now your backend is in Java because you only have Java devs available (this has happened to me at LEAST once, I'm a Unity & C# fanboy after all).
Whatever you choose to do, make sure it works for your situation and your team.