I think I have fixed the rendering of the Ottawa River near Ottawa (I noticed the problem as well). These river multi polygon relations are very fragile, you almost have to download the whole thing to make sure they are not broken.
DannyMcD

Yes, the southern one should be 558. I have corrected.

way/59374791 is a informal path through empty land, way/591876842 is a new, paved, multi-use path. I can add surface when creating new paths.

Looking at it, my edit yesterday was fine, the problem was that I had previously (in March) transposed 3399 Paul Anka as 3339 Paul Anka. I have corrected this.

The House Number Editor plugin that I use doesn't allow setting unit numbers, so I usually set the unit numbers as addr:housenumber, and the actual house number as addr:state (which I use because it should not otherwise be used). Once I have tagged all of the units of an address, I just correct the tags. I forgot to do so in this case.
I plan to occasionally do Overpass searches for addr:state to catch stray mis-tagged addresses. There are no other uses of addr:state in Ottawa right now.

Searching for the address, it looks like 103 Tay is correct. This is a new (not yet occupied) duplex - the footprint is no longer correct, even the Esri imagery is wrong. More generally, I don't think that the side with more street frontage always has the address - it is usually the side with the main entrance.

The railway right-of-way still exists on the ground - it is clear that these paths used to be rail lines (e.g. from the gentle grades and turns). Worldwide, rail trails almost always have railway=abandoned, from the Tammany Trace in Louisiana to the Ruwer-Hochwald-Radweg in Germany. I will be re-adding the railway=abandoned tag.

All these paths are abandoned railways, so the railway=abandoned tag seems appropriate. Is there some reason for removing it?

I have corrected this. I think this error was due to my mis-interpreting a CanVec address node as a real address node.

I was trying to get residential landuse to render over woods. Adding layer=1 doesn't work, as I learned from this experiment. I've removed the layer tag.

I think (long-lasting) Airbnb listings are fine for OSM - they are effectively guest houses. Also, please don't delete buildings - just remove offending tags.
DannyMcD

This is a mistake that happens when merging addresses in iD. I have fixed it (by deleting the relation)

Hi Undearius,
I'm not sure I like these proposed buildings being tagged as building=proposed - maybe proposed:building = retail would be better? They show up now (in Mapnik+probably OSMAnd?) as normal buildings. which is confusing, since they aren't actually there.
DannyMcD

I was using the .shp file (from February). The more recent .csv file seems to no longer have the addresses on 995+997 River Rd. This means it only lists some of the units in the complex (41 units instead of 70). One mistake replaced by another...

391 Millcraft should be on Irwin Miller - I have corrected. 995&997 North River are OK - the city mistakenly lists them as being on River Rd (the old name of the street).

Je pense qu'il y a eu un malentendu ici. Après avoir reçu votre premier message, j'ai pensé que je communiquais que je fusionnerais les frontières parallèles. Je pensais que tu faisais aussi ça. Au lieu de cela, je vois que vous avez réarrangé les frontières pour qu'elles ne soient plus parallèles, ce qui est une tâche beaucoup plus difficile. Ma fusion des frontières a effacé votre travail, malheureusement. Je m'excuse.

J'ai dit que je corrigerais le problème de la frontière parrallèle, et je l'ai fait. Je ne suis pas sûr de ce que vous voulez dire en effaçant votre travail - pourriez-vous clarifier?

La plupart de ces erreurs sont attribuables au fait que j'ai recréé la frontière entre le Canada et les États-Unis, dans le but de limiter le nombre d'éléments dans la relation entre le Canada. Ma bordure recréée croise la bordure actuelle. Je vais réparer ça.

Yes, the addresses should be 35 to 41. I have corrected this.

Shopping mall units seem to be little used, and hard to find. addr:unit seems appropriate when they do exist
I don't think it makes there is a big difference between putting the qualifiers in addr:unit or addr:housenumber, although consistency is good.