I think it's a useful option, if the byte-order handling is already taken care of externally. For example I have a use case where values can either be programmed to an EEPROM directly, or sent via CANopen. If the EEPROM representation is already known, it makes no sense to parse those bytes into an integer and then re-encode that to the CANopen little-endian format.

Another use case would be strings with a known encoding, bypassing the encoding for the two expected string object data types. Or even completely free-form OCTET_STRING objects, which need to be passed in verbatim. I actually do have such a thing in use, for a two-dimensional array of values which is stored in a single CANopen object entry.

So I don't see how this could be not useful. It should definitely be kept.

OCTET_STRING and DOMAIN support but maybe it could be more strict to only apply if data type is actually that.

On a second review of the code, I see that encode_raw() have the override ability by inputting the data as bytes or bytearray as discussed. However, decode_raw() does not have this ability.

@acolomb have a good use case: If the assumptions on encoding e.g. for UNICODE_STRING is wrong. I.e. an application wants to use something else than "utf-16-le", then this becomes a way to override the library behavior. -- But then we need it in both directions.

Well it's useful as is. If one wants the undecoded bytes from an upload, there is always a possibility to use one of the lower level methods, where no decoding is done at all. I don't think we need perfect symmetry here just for the sake of it.

Thanks. I got the answers I was looking for.