SMAPI should provide a way for mods to create custom items without needing to worry about ID collisions, patching the game's spritesheets, etc.

I would like to report that the latest release version of Entoarox Framework uses a interface-based implementation of this mechanic, for multiple types (Item, GameLocation, Building, etc.)
The support is as simply as having a ICustomItem interface on your custom class, although having factory classes that make things even easier would also help a lot, these are not currently provided by EF.

Thanks! This ticket is outdated; with framework mods providing better custom item support, I'm going to focus on other priorities for SMAPI. We might revisit this in a future release, but I'll close this since there are no near-future plans for it.

Will this de-/serialization be accessible for other uses? For example, my unreleased mod sometimes needs to serialize the shipping bin. I imagine the mod that lets you send items to other players could use it too, etc.

They could even create their own subclass of CustomObject if needed.

How will this work with step 4?

Will this de-/serialization be accessible for other uses? For example, my unreleased mod sometimes needs to serialize the shipping bin.

Probably not. SMAPI would need to serialise objects in a pretty specialised way so they could be safely stored in the save file. For any other uses (like storing data elsewhere), you can just use straight JSON instead.

They could even create their own subclass of CustomObject if needed.

How will this work with step 4?

Probably store the object type and use that to rebuild the object later if it's still available.

One option is...

1. Add item subclasses like CustomObject, CustomFurniture, etc.
2. These would override the draw methods to use the given texture (so mods don't need to patch the game's spritesheets), override properties to avoid reading data from the game files, etc.
3. SMAPI would replace custom objects in the save file with a safe structure that won't crash if the player removes the mod (e.g. serialise custom details into the description field).
4. SMAPI would deserialise them back into custom objects (if the mod is still loaded) after save/load.

Mods would no longer need to worry about the mechanics of custom items beyond using SMAPI's subclasses. They'd just create their custom object:

var item = new CustomObject("name", "description", ..., texture);

...and use it, without needing to do anything else to avoid save issues or patch game files. They could even create their own subclass of CustomObject if needed.

Is there anything in particular others could to help speed this along?

It's tentatively scheduled for SMAPI 2.0 in ≈August/September, since I'm not planning any more big 1.x releases after today's 1.15. It might be pushed to a later 2.x release, depending on whether we run into trouble implementing this and how much time I need to spend updating mods for 2.0.

If you want to help, a proof of concept CustomObject with the behaviour described above would help a lot. Doing it in SMAPI would be ideal, but a mod using SaveEvents.BeforeSave and AfterSave would be okay too if you're more familiar with that.