Using CinGG compiled with your patch, I ran some tests with an H.264/MP4 source file and an audio track. When I set g=1 and b=100M, I keep getting the same errors.
If I don't render the audio and set g=1 and b=100M, everything works fine. The resulting file is 2.1GB.
When I don't render the audio and don't use those two parameters (i.e., using the original preset), the rendering works (file size is 25.3MB), but I get a long list of warnings:

file:/home/paz/test_avc.mxf
  err: Not yet implemented in FFmpeg, patches welcome
FFStream::encode_frame: encode failed.
file: /home/paz/test_avc.mxf
  err: Not yet implemented in FFmpeg, patches welcome
FFMPEG::mux_video  err: Operation not permitted
FFStream::write_packet: write packet failed.
file:/home/paz/test_avc.mxf
  err: Not yet implemented in FFmpeg, patches welcome
FFStream::encode_frame: encode failed.
file: /home/paz/test_avc.mxf
  err: Not yet implemented in FFmpeg, patches welcome
FFMPEG::mux_video  err: Operation not permitted
FFStream::write_packet: write packet failed.

The difference in size makes me think that our mxf_avcintra_100.mxf preset is actually of the LongGOP type.

I found some old FFmpeg bugs (not in FFmpeg 8, though) related to LongGOP sources that caused problems when converting to MXF. I also found other old bugs that mentioned that transcoding to MXF could cause problems due to Annex-B (which I don’t know what it is). For example:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/AM7PR03MB66600B2742E305A97C277D898F929@AM7PR03MB6660.eurprd03.prod.outlook.com/
Could they be related to our case, even though we're using FFmpeg 8?

P.S.: I'm sorry, but I won't be around for a couple of days.