Can you describe your use case so we can provide the most accurate recommendations?
You are free to do pretty much anything and the Flarum API gives you a lot of power. For more advanced use cases you can use your own controllers, own serializers or even ignore the JSON:API spec at all.
If you are extending existing API endpoints I would recommend following the JSON:API spec so potential users of the REST API don't have any surprise.
It doesn't seem like the spec explicitly forbids duplicate resource identifiers in relationships, however they cannot have attributes https://jsonapi.org/format/#document-resource-identifier-objects
You could use the meta key for non-standard information. But if it's for pivot table information, I would also suggest creating a new attributes on the model itself and include the information that way. A custom property as an array could be an ID-value list. Then the models could still be included as a regular relation if you need access to them.
Another option could be to create virtual resources that describe the pivot as a model. The relations could point to those virtual objects that are dynamically created, their IDs can be a composite of the 2 pivot IDs. Then those virtual models have relations to the actual model from the pivot table.
