What problem are you facing?

OpenTofu is adding support for .tofu files in addition to .tf files. Terraform only supports .tf files, and OpenTofu will support both. This will allow users to have tool-specific configurations in places where it matters (e.g., provider functions landing in Terraform 1.8 and OpenTofu 1.7, and wanting to gate-keep the CLI tool by version).

If two files have the same name with each file extension (e.g., main.tf and main.tofu), OpenTofu will execute main.tofu and NOT main.tf, while Terraform will execute main.tf.

It's still all HCL syntax in these files.

How could terraform-docs help solve your problem?

I don't believe that generating two sets of documentation is the right approach — one for Terraform, and one for OpenTofu. Instead, I believe that in cases where .tofu files exist, the OpenTofu configuration should be provided in tandem with the Terraform configuration.

For example, in the JSON output, requirements is an array of objects, with each object defining name and version. Perhaps this could be modified to support "name": "opentofu" with its version, and for any providers/modules, there is a new tool key which contains an array of tool identifiers (e.g., terraform and opentofu).

This would allow flexibility in the future in case (God forbid) another fork happens in the community. This also shouldn't (AFAIK) require any backwards-incompatible changes.

This would also mean that for content, it would be useful to define .IsTerraform and .IsOpenTofu variables, so that users can adjust the examples or other custom documentation to more specifically target each tool.

Ways for readers to switch between the two flavors of tooling could be either a tabbed interface (and a nice touch would be like many API documentation websites where if you select a preferred language in a tabbed interface to view those examples, that all other examples switch to that same language too) — OR something simpler, but less "nice" like a <select> HTML field where you can select which version to view.