I have a similar plugin with a client site’s custom post types and some other functionality that should persist between themes. I’ve kept the plugin in its own repo and listed it in the bedrock composer.json. To see changes immediately while developing locally, I set up an extra vagrant share folder for the plugin in my Trellis vm.
As a side note for context, my understanding is that the recommended practice is to commit a developed Sage theme to the client’s Bedrock project and that you’d probably only really keep the theme separate if it were going to be used in many different projects (e.g., for sale and redistribution).
Back to plugins: A major point of moving some functionality like post types into a plugin is to isolate the more permanent features from the less permanent theme styles. So, to borrow the theme-in-bedrock rationale, if one’s plugin is specific to a client’s project and won’t be widely redistributed, perhaps it should be committed to the client’s Bedrock project as well (?). Maybe the plugin’s distinction of housing the more permanent features/functionality gives it an even stronger argument for inclusion in Bedrock (?).
I dunno, but the client-specific plugin I described above is starting to sound like a good candidate for inclusion in my Trellis+Bedrock+Sage repo, maybe autoloaded as a must-use plugin. Somebody stop me before I make a poor decision.
As @jwkicklighter already considered, if the plugin were part of my Bedrock directory, I’d see local dev changes to the plugin immediately because vagrant syncs the whole Bedrock directory. I wouldn’t have to hack in an extra vagrant share folder for the plugin.