Yes, I don't need any bus expansion - or I did need one, I could have used a SPI-connected FPGA or the Maxim chip linked in the other thread, for low-speed signals to reserve direct-mapped pins for the real task.

In total, I have maybe 50-70 signals that I currently don't know the data direction for, but probably 50-70% outputs.

I might be able to lock down some of them as always in or always out, but I would prefer to not have to.
I might be able to lock down some of them as possible to drive at a lower speed (such as through a SPI-controlled port expander) but would prefer not to.

My problem is that I do believe I might actually need pin-by-pin direction control, or alternatively I might need a design with a potentially large number of pin headers (or a large set of different plugin adapters) to adjust for the varying interface design. It's just that the connected equipment are designed by different companies and/or different designers, with the individual standards having evolved over maybe 20 years.

If I trusted the technicians installing the equipment, it would be possible to connect microcontroller pins directly, but a real buffer chip (togheter with a series resistor) have better cooling potential in case someone turns a ribbon cable the wrong way and tries to short 8-10 data signals at the same time. The processor can survive quite a lot of abuse, but many shorted pins would quickly take it over maximum total output current and over maximum allows power dissipation. And moving 100-pin => 1444-pin => 208 pin for the microcontroller will add lots of extra pins but without increasing the max allowed power dissipation/max total current sourced/sinked more than marginally.

Same thing happens if the ribbon cables are connected the correct way, but the technician forgets to connect power to the external equipment, in which case my side have to fight with grounded body diodes. For the current design 74HCT245 are used, and they can stand this abuse continuously without a problem as long as the ambient temperature is reasonable. But the current design only works with one brand of peripherial equipment, with one fixed set of pinout and signalling.

Yes, I most definitely need direct pin mappings, since I have reasons to want to toggle more than one pin at a time. A 40MHz SPI bus would allow quite fast changes for a single pin, but if the ribbon cables happens to contain a number of clocked serial interfaces, there would be quite a lot of pins to set and read back concurrently. It is likely that at least 20 signals (at unknown position) needs to be run at 1 to 5MHz, or alternatively maybe 40 pins at >= 250kHz, depending on connected equipment.

5V - yes, I would be happy to only need to support 3V3. But there are maybe 100+ different products, conforming to maybe 10 different standards, that needs to be supported. It would cost quite a lot to redesign them to use 3V3 logic. But I would most definitely like new designs to consider 3V3, and have "my" side be ready using a strap, transistor or similar for selection of 3V3 or 5V for the I/O. 5V really is ancient. But then it would probably be better for a new design to contain a microprocessor with CAN, USB or Ethernet and instead run at "bloody high" serial rates with twisted and potentially shielded cables. Alas, such alternatives are not possible because we are talking about existing equipment, and we are talking about multiple manufacturers and multiple standards.

I have of course considered FPGA, but a question there is their capabilities, in relation to the noise protection and high current capabilities of traditional line buffer chips. How much does it like accidentally feeding an unpowered transceiver chip on the other side of the cable for hours with say a 33 ohm series resistor as current limiter? The FPGA I have looked at earlier have not been able to match bus transceiver chips, and ribbon cables are not the best way to communicate out in real-world installations.

The need would be for 10k+ units while production cost is critical - each dollar/board quickly adds up to real money. And incorrect installation or blown fuses may require multiple FPGA just for better total power dissipation. It would of course not hurt if it was possible to read back the state of an output pin to tristate the drive in case of a detected problem.