About the only place I can think of where highway=footway would be appropriate for something that allows bicycles is the edge case of mapping a sidewalk in one of the rare areas (in North America at least) where operating such a vehicle on the sidewalk is OK.

The correct tagging would be either ...

This is frustrating - why are both possible? Is one more correct than the other?

Mappers can tag what they like - depending on your point of view it's either the great weakness or the great strength of the project.

For more on highway=path vs highway=footway/cycleway search the mailing lists (if you're suffering from insomnia)

bicycle=yes on footways is the representation for an actual traffic sign in some jurisdictions (e.g. Germany) that allows bicycles on footways (legally this is neither the same as allowing pedestrians on cycleways nor is it the same as a shared footway and cycleway).

Users are generally not faulty, they just trust what the common editors allow them to do without warning them.

Merging ways with distinct tags or not members of the same sets of relations should open a conflict resolution editor allowing to see the differences and accept merging tags, or reject it (notably for distinct relations, these relations need to be merged separately if needed, using the same checks on tags and sets of parent relations)

The same remak applies when splitting ways (here also the parent relations need to be all updated in their lists of members), but most often it is simple to repair if a relation is forgotten.

In JOSM, the set of parent relations is not automatically loaded for all ways when merging or splitting them: but JOSM still does not automatically download the parent relations. You have to do it just before merging/splitting ways, pressing CTRL+ALT+D.

However the data server frequently returns 5xx errors when looking for parents (this error isn't reported by dialog or notification on the screen: you see it only on the console, provided that JOSM is launched from a command line window to see it, or by enabling the console window in the Java config menu. Unfortunately, if you close that window, there's no way to reopen it. Suggest JOSM to add an panel to show what is sent to the std-output.

If the server returns an error, nothing happens in the editor, users may feel that all parents are loaded, when they are not. The work around (if you see this error), is to zoom in on a tiny area around the node of the way to split or connecting ways to merge, and then download all objects in that area: the OSM server does not fail downloading all parents of these ways, when it fails by querying only the lists of parents and loading them: this is still a bug/performance issue on OSM server!

In the ID editor, there's a separate old unsolved issue, which occurs when splitting ways that are members of relations: the newly created way is just added at an inaccurate position at end of the list of members, instead of being inserted immediately before or after (depending on the connection of the other end nodes with other members before or after that way).

This creates havoc in many relations that expect a correct ordering, and complicates a lot the reparations that could be done later when the geometry needs to be repaired (not just for closed rings in multipolygons, but as well for linear objects such as associatedStreets/rivers...).

ID should preserve the continuity of member ways as much as possible, and when splitting ways, it is evident that both parts should NEVER be separated in the list of members.

Getting the topology to match what's on the ground is important to routers too - it makes the difference between "take the second exit from the roundabout" and "take the first exit".

What's the correct way to tag which way is discharged into the other?

you do it geometrically, if it is not clear maybe it really isn't clear in the particular situation.

If you are after names or reference numbers you could see these as well, but in some special cases the name (maybe even the ref) don't follow the "main flow". (e.g. could imagine a road intersection, where continuing leads to a higher road and the current ref turns into "another" road).

That's not so different from other countries. The highway tag should be used to tag the road classification, not the road's look.

Fortunately, this is enabled by default.

Oh, that's right, it is. My mistake. I must have forgotten that early on I disabled it so I could see the pretty slippy map background clearly.

Long distance routes (notably motorways or national/interstate/state/regional highways) have a common descriptive name, but the actual identification is their ref number. That ref may be placed on member ways, but individual ways of course keep their local name (notably streets in cities/towns/villages), as defined by the local administrative authority. Even if this is the same administrative authority that manages the whole route, it still has distinctive local names for sections, e.g. for circular highways around towns/cities.

For standalone ATMs (not part of some other feature) "amenity=atm". If the operating bank is indicated, then also tag with, eg, "operator=Citibank". I've never seen a standalone ATM with a name (eg "Jimmy's Cashhole"?), but the world is full of wonders.

It's tempting to name them after the operating bank, so the bank name will render on the map. But of course that's a no-no, "tagging for the renderer."

To indicate the presence of ATMs as part of another feature, tag with "atm=yes". If that feature is a bank, that bank would be presumed to be the operator. If that feature is not a bank, very often the ATM is no-name and doesn't need an operator.

But of course there's always an exception. For instance, in New York the Duane Reade pharmacies usually contain ATMs operated by Chase Bank, and it would be great to be able to tag them as such. We might consider something like "atm:operator=Chase" after the "atm=yes", or just skip the "atm=yes" and create a separate "amenity=atm" node with "operator=Chase".

As far as Domino's pizza goes, "name=Domino's" or "name=Domino's Pizza" (whatever the sign says) and leave the operator off unless you observe specific operator data.