Current solution is integrated into a client's bespoke component, so nothing which can be shared.
If asked for again I would consider something along these lines:
Custom field on product table listing the bundled product IDs in a JSON type structure.
Custom field on prices table listing those product IDs, quantity in bundle and attributed revenue, again in a JSON type structure.
Custom field on order product table which is a copy of above at time of order (in case bundle definition changes later)
This could handle a shop selling an alarm system consisting of a central station and sensors.
Each item could be purchased separately.
Bundle 1 could be central station and 5 sensors.
Bundle 2 could be central station and 10 sensors.
Additionally if they purchased 5 bundles, say, then could get 5 extra sensors free (hence quantity in price table).
The attributed revenue field would never be seen by the customer but would be available to the shop in the admin screens for internal book keeping. It could be used, for example, if the bundle included an installation option. The shop's agreement with the installer being that it is a fixed price fee which is passed directly onto the installer and never discounted. The shop's revenue in this case being the price of the bundle less the installation fee.
That's the simple bit, next would be the requirement for an administration screen.
Then there are the rules - for example
Handling of products not available separately.
What happens to the bundle when a product is unpublished.
Maintaining / displaying stock quantities.
If stock low should bundle or single product take preference (e.g. if less than 20 in stock should the bundle show as out of stock or should it be the single product)?
Making sure weight of bundle matches sum of weight of products.
Making sure prices make sense (i.e. bundle would not normally be expected to cost more than sum of products!).
I expect further questions would come to light if someone starts to implement something on these lines.