Due to some weird concomitance of odd application requirements and legacy code to maintain, I am currently stuck having to programmatically create some list items on a SharePoint 2016 list and assign each of them a custom hardcoded ID (and yep, I know that is generally not a good idea, but as I said... it is legacy code that a) we don't wrote b) will probably have to stay as is for now).
Since normally the item ID is an autogenerated value, I searched for a confirmation that it could be also set programmatically and found this answer. Without going into further details on the actual code used in the linked post (some part of which imho could be not actually needed), let's just consider the actual line that sets the ID field value on the list item
listItem[SPBuiltInFieldId.ID] = someValue;
As you can, the original code provided by the answer uses the ID field GUID to access the field setter. Due to a mere case of sheer bad luck, without even noticing at first while applying said code to my actual situation I altered it a little, to use the field internal name instead.
listItem["ID"] = someValue;
To my surprise, when I tried to execute my code, an exception was raised on the above line, with an error message "Can not update the field value".
I started debuging my code until - to even more surprise - I discovered that if I used the first variant of the setter (the one that uses the GUID) the code would work as expected, while the second variant would fail.
Since both field value accessors should access the same list field, I wondered how that would be possible.
NOTICE: I didn't attempt to replicate this behavior on others SharePoint version so this "bug" is only tested on SharePoint 2016 for the time being. For that reason, I haven't yet added any version specific tagging on this question since we still don't know for sure if the issue is version specific in the first place.