Original issue here on forum

Most CAN buses can handle messages with both extended- and standard-id but the current API does not allow mixed id-type bus.

There could be hardware modules on the bus with varying degree of tolerance for even the presence of extended IDs:

Concerning the compatibility of standard and extended frames three types of CAN controllers exist:
˚ CAN controllers according to CAN protocol specification vers. 2.0 A, which are able to receive
and transmit standard frames
˚ CAN controllers according to CAN protocol specification vers. 2.0 B, which are able to receive
and transmit standard frames and to tolerate extended frames without detecting an error
(’extended frame passive’)
˚ CAN controllers according to CAN protocol specification vers. 2.0 B, which are able to receive
and transmit standard and extended frames (’extended frame active’).

While it does make sense to say this can bus can only accept standard-id, it doesn't make sense to say this can bus can only accept extended id because if you can accept extended then you can also accept standard.

Therefore, the flag in CAN.init() should be changed to indicate whether or not the bus allows extended ID and CAN.send() should be modified to accept a flag to indicate standard vs extended ID and throw if an extended-message is attempted to be sent on a standard-only bus.