In homage to the POM Port how about Plug In Protocols (PIPs) if the code space would get a little crowded with a bunch of specialty protocols. Each bringing the firmware support, specialized heap structures and instructions. Some might have do be associated with specialty add-on modules if the protocol requires such hardware. Possibly a profit center if needed.
I like the idea. Implementation is hard.
In a system with an OS that supports dynamic linking, this is easy. In a PLC built on bare metal, not so easy.
If there is enough business to justify a module-based implementation, that's a fairly easy answer, however we are still very far away from the point in BRX development where we can justify the time to develop narrowly focused specialty modules. To further complicate the decision, unless ADC specifically requests it due to them feeling like there is a large enough market to justify it, Host is just rolling the dice if we develop such modules.
Another less obvious aspect is that if you sell an expansion module there is an expectation of a more complete implementation, which can be deceptively time consuming. A minimalist implementation as a built-in protocol is often good enough, and requires far less work overall.
The POM port does give us nice options for slave side protocols. Turning the ECOMLT hardware into simple slave protocol converters might be a nice middle ground. The hardware cost is low enough that minimalist implementations wouldn't be bad, and I would think most customers would be willing to spend $69 to add a protocol they needed.
That doesn't answer master side protocols though. That's a much bigger problem, and will likely remain the domain of full expansion modules and robust markets...as time permits.