There are a couple of recent request for change or issues that asked for a change in the API:

• export QRCode Mask (QRCode: add QR data mask to Barcode result #849)
• allow to force a QRCode Version during encoding (QR Code: add the possibility to set a fixed version #861)
• allow to lower the minimum length for ITF symbols (ITF Barcode Recognition Fails Due to minCharCount Limit of 6 Characters #853)

All of them have in common that they are

1. pretty niche in their application
2. specific to only one symbology
3. need an API change

Given that there are so many wrappers now that need to be kept in sync, which incurs a substantial maintenance cost, there needs to be a pretty high value added for justifying this, in my opinion. The simple addition of a new BarcodeFormat::DataBarLimited constant, that I did recently, already took me a substantial chunk of time. None of the 3 mentioned issues would cross that threshold for me.

As mentioned here, this reminded me of the meta data key-value map type data structure in the original Java API that was solving basically this use case. I didn't like that complex API design, though. So my idea would be to use the simplest and most generic channel to communicate this kind of data: a JSON string. Once established, it would completely eliminate any work across the wrappers when adding yet another bit of info. On the down-side, it would require the client code do deal with JSON if they are interested in the "extra" information and could lead to a bifurcation of the API since once we have that, why then not add all the existing bits of data to that JSON string as well?

EDIT: Looking at the current API, I would then in the long run (3.0) move existing members into that JSON channel:

• Barcode: readerInit, version and potentially also ecLevel and lineCount
• ReaderOptions: obvious candidates are tryCode39ExtendedMode and eanAddOnSymbol
• CreatorOptions: forceSquareDataMatrix and readerInit.