You're still making many of the same errors lots of people have been telling you about. Please stop or the community will need to involve the Data Working Group to make you listen.

I don't understand why you would revert a reversion of a mechanical edit, based on that reversion being a mechanical edit? Do you even have any knowledge of what was happening here? The landuse of these areas was improperly removed, and should be restored. We'll see what the DWG does.

There were still 5 unnecessary or non-standard tags on the two BC ways, so I've removed those.

Someone reported that you've added surface=asphalt tags to every node in these highways. It looks like addr:province was also added at the same time. I assume these were mistakes and can be safely removed?

Can you explain what's happening here? It seems like some reserves in BC are being tagged with some Nova Scotia information, as well as a number of very odd, non-standard, or outright wrong tags (type=land_area, place=Mi'kmaq Reserve, reserve=first nation, etc.). Was this a test that wasn't meant to be uploaded?

Thanks for explaining.
As far as things reported by OSMI, I'd like to point out that it isn't an "error program". It's one of many quality assurance tools that highlights "potential" issues. Not everything reported by these tools is necessarily a problem. Sometimes there are edge cases where it actually makes sense to map something in a way that a QA tool reports as an issue. Please don't try to "fix" everything reported by OSMI.
As for the way length, keep in mind that it's a rule-of-thumb, not a hard rule (or the database would enforce it during uploads). If you have issues selecting things in iD, I'd suggest that you start using the more-advanced JOSM editor. It's far better for making more complex edits. As for selecting long ways, it's simply something that you need to get used to; when you're trying to work on a long way, you may need to download data near an end/bend node.
Having a two-node way in this case isn't a case of sloppy work. This way can be represented fully by two nodes, so there simply isn't any need to add superfluous nodes. Whenever possible, you should try to minimize the number of objects you use to represent an object, because otherwise it bloats the size of the database, making it harder to work with for data consumers. For example, while a curving road could very accurately be represented by thousands of nodes very close together, it's overkill and unnecessarily creates extra data that consumers would need to process. In the case of this seamark way, two nodes is all that's needed to represent the straight call-in point line. The extra nodes really don't serve any purpose. Sorry, but what I find silly is using 13 nodes to represent a single straight-line feature.

I can't say that I understand why a bunch of additional nodes were added to a straight line, but I guess they aren't harming anything. FYI, though, that there isn't such a thing as "too long of a segment". Some tools may highlight these in case they indicate a problem, but legitimately long ways (like in the case of borders, rivers, etc.) are just fine.

Can you explain what you mean by "no longer needed"? The landuse of these areas hasn't changed, so this tag shouldn't have been removed.

This way was tagged with "seamark" tags for maritime-related use, so I've restored it.

Since the abandoned pier isn't actually a usable pier anymore, the man_made=pier tag can be misleading for data consumers that don't check for additional tags like abandoned=yes. Instead, I've changed it to abandoned:man_name=pier, which is a safer and more widely-accepted scheme for representing an object's lifecycle.

Some highway_1 tags got mistakenly created during these edits, so I removed those and replaced them with "foot=yes" on the relevant tracks.

These kind of Canada-wide changes should probably be discussed within the Canadian OSM community first. Were these changes discussed anywhere? I thought the tagging of the Trans-Canada route relations had been settled a while back.

The timing of these edits wasn't the greatest, because a construction project that will be physically dividing a section of the highway should be complete within the next month. Also, please don't create fictional turn restrictions. I'll leave most of the edits from this changeset intact because they do reflect the current reality (even if it's only for a few more weeks), but I'll be removing the fictional turn restrictions when I get home tonight.

This branch is located much farther south in Richmond, not inside the YVR terminal. I've moved it.

Most of these were in the wrong spot, duplicated an existing object, or simply don't exist. I've fixed them all, but please be more careful before you do an import like this.

I drove up here and checked today, and these roads are definitely still under construction. I don't know what source you used that indicated these roads were complete, but that source is apparently not reliable. I've reverted this changeset.

I went over and checked today, and this road is still under construction, so I've reverted this changeset. Whatever source you used is not reliable.

This changeset created a number of objects that duplicate existing objects, especially on Vancouver Island. Can you please remove the duplicates and use the existing objects in the new relations?

What is your source that indicates these roads are now open? The last time I checked, they were still closed.

This road was still under construction when I drove past it a couple of weeks ago. Do you have someone in this area that reports it is now open?