That might be a very nice enhancement!
In the meantime, is it possible in your use case to batch the messages in the Publisher (publish x number of messages in an array), while still operating in near real-time? Of course, you need to be mindful of the Pub-Sub message size limit, which was 64KB but I believe was recently increased to 128K.
We have an interface that runs near real-time (polls every 5 minutes) and it publishes up to 1,000 messages per "Publisher" job. Due to the Pub-Sub message size limitation, we publish only the primary key (PK) for each record. The subscriber receives the 1,000 PKs and calls a helper or utility recipe to retrieve the 1,000 records from the source application, maintaining the Pub-Sub pattern advantage of decoupling source from target. All processing is done in bulk/batch and It runs pretty fast end-to-end. We have concurrency set to 5 for all 3 solution components (the Publisher, the Subcriber and the Utility/Helper recipe). We will be adding a second Subscriber in the coming weeks.
Also, we considered a Datahub approach where the Publisher would write each new/modified event to the hub near real-time and each subscriber would retrieve however they want/need from the Hub (event-driven or batch/bulk, timing/frequency, etc.). However, we opted for the ligher weight solution that I mention above as a full blown datahub, with its requisite on-prem DB components, was not warranted for our requirements.
