There are literally hundreds of static site generators: https://www.staticgen.com
Most of them should get markdown right too!
Incorrect DOM-output is likely caused by common mistakes (e.g. conditional rendering based on `typeof window !== 'undefined'`) which screw up rehydration. Dealt with it in the past and seen a lot of developers struggle with it. This article describes it well:
https://joshwcomeau.com/react/the-perils-of-rehydration/
Gigantic page-data.json files are caused by querying more data than necessary to render a given template/component. Let's say you define a component named `EmployeeCard` that renders a name and photo given an `employeeId`. Now you need to query all employees and render the right one using `.find()`. All this data (including base64 thumbnails) ends up in page-data.json, even if you need to render a only single employee.
This is solved by querying only the relevant employee(s) in the template and provide the data (name + photo) directly to the `EmployeeCard` component as props.
I've developed quite a few websites using Gatsby (mostly backed by various GraphQL API's such as WPGraphQL and Strapi) and while there's lots to learn, it's been an enjoyable experience so far.
For example, we have what roughly amounts to an <Include> component. It uses some contextual information to include language-specific code. That include component pulls in a markdown file from disk based on 1) the includePath you set, and 2) the language selected. In order to make this function, we have to pull in _all_ possible includes within the static query, and then filter it down to the ones we need. There is literally no better way we could do this, because static queries are exactly that - static. There is no fixing this problem because the design of this data layer is broken by default.
The basic idea is your page context just contains identifiers for the content you need to display on the page and then the page query uses those identifiers to query for just those objects and request all the properties of those objects that the page needs.
You could publish the different languages in different folders/path, thus, using the static queries to build static pages.
If you want them on the same path while loading different language content dynamically, that migh not be the best use case for gatsby. In that case you probably need to load every translation for each of the included paths, but not every path with every language for all of the different pages.