Cas 1 ou 2, je pense qu'il sont finalement pas si différents et qu'on a 3 cas.
On a 2 jeux de données A(ncien) et N(ouveau), l'un qu'on considère comme plus à jour que l'autre (ne jamais parier là dessus, mais bon).
Il faut faire une conflation entre les deux et on a 3 cas de figure:
- même objet potentiel dans A et N, on va combiner les deux: garder les attributs, les compléter/mettre à jour, remplacer la géométrie A par N
- objet dans A et pas dans N: il faut le supprimer si on est vraiment sûr que A se trompe

- objet absent de A et présent dans N: il faut l'ajouter (le cas presque facile)... en vérifiant qu'on n'a rien d'incompatible à cet endroit là (genre une route alors qu'on veut ajouter un bâtiment)
Tout ceci est potentiellement scriptable, mais la communauté OSM n'aime pas trop les automatismes qui modifient les données (imports, bots). On a trop eu de cas où finalement on a passé plus de temps à corriger qu'à faire une intégration contrôlée.
Une fois qu'on a la liste des modifs à faire, on peut soit générer un fichier .osm qui contient les modifications, soit faire des appels à l'API pour faire les modifs dans la base.
C'est ce que je fais par exemple pour ajouter les tags sur l'orientation des toits pour OpenSolarMap. C'est un script python qui se connecte directement à l'API pour faire ça à partir des données stockées dans une base postgres. Le script est sur
https://github.com/opensolarmap/solback ... -upload.py