Hmm. Crazy thought, but there must be some sort of save data function. I wonder if one could exude a ram chip(as opposed to short life flash or eeprom back then) as a storage device, with some fake filesystem, then have the software write updates to that.
As ram, you could read the data on the cartridge, modify it, and thus fake bidirectional comms?
Even if the bus/protocol is limited to "only" disk I/O, you could still have the controller interpret reads/writes to certain addresses as requests for other actions, including interaction with other hardware on the card
From what I can see, it looks like even though they can't extend the functionality directly, they do still interface with the system in some way. Perhaps they are more like a device connected to a serial port would be? So far less capable than the full extension cart, but still possible to communicate with through a standardized protocol? (The DS Cartridge slot has 8 data pins rather than the full address/data bus, but seems to have a protocol: http://problemkaputt.de/gbatek.htm#dscartridgeprotocol)
So, I need to correct myself, they nerfed it first with the DS, before then switching to being pure flash chips with the 3DS when they switched to XtraROM (which has potential lifespan issues: https://gbatemp.net/threads/nintendo-switch-3ds-cartridge-li...) - and that seems to not allow much custom functionality: https://www.3dbrew.org/wiki/Gamecards#Protocol
(Though if someone with more knowledge can correct me, please do so. I thought that DS/3DS/Switch are pure flash chips, but was wrong at least about the DS)