(just added myself to the mailing list so I can include reply history to the topic. This message touches on both Jaap's and Roland's comments)
Profinet and Ethercat were the 2 protocols I was most looking at to convert to built-ins. Being in the industrial protocol space, they are (could be) the most useful to me. I've looked at the Profinet code, and I don't really think it can be squeezed into a single file. There are multiple protocols, each with drastically different dependencies(DCE/RPC for I/O and DCOM for CBA), but also "common code" as well (packet-pn.[ch]).
While I see "grouped protocols" in the current epan\dissector directory, I thought maybe Profinet could have its own directory off of it if otherwise 'pollutes' the main dissector directory. I just see the plugins directory as "Windows only", and I don't think any protocol should be limited if there isn't anything "Windows specific" about it. My goal is to just increase "platform independent" code.
The part of Jaap's message that I sort of understand is the request to keep dissectors as plugins for proprietary reasons. Profinet/Ethercat/Modbus/CIP are all proprietary protocols (as I assume there are many others that Wireshark dissects), but I think Modbus and CIP have taken the attitude of having Wireshark know about the protocol increases their use so they are more apt to let it go. Perhaps the Profinet and Ethercat organizations don't feel the same way. It sounds like part of "development speed" is that plugin updates be can distributed via the DLL much faster than Wireshark publishes releases (doesn't everybody want their patches to be applied ASAP?). What also confuses me is the GNU licensing part of it. If the code is there anyway, what is being protected? Are they worried a novice developer will submit a patch that messes up the dissector? Unless the core developers have been given instructions to only accept patches from particular people, that could still happen with the plugin.