Did you actually check the NSI link? Or review the wikidata item? Q41171672 is being used with both, brand=ALDI and brand=ALDI Süd, based on the country (see NSI link above). In the US, all stores are branded as ALDI (not ALDI Süd). That's what the name and brand tags reflected after my change.
Q1250054 doesn't have a brand entry anymore in NSI - For a very good reason - There is no such thing as a single "ALDI". There are two completely independent companies (different shareholders, different management, different headquarters, different product on the shelves, different markets), both calling their stores "ALDI" in one country or another. Capturing both under the same brand tag is semantically incorrect (and has been handled in this incorrect fashion for a long time). They are not the same brand.
None of this has anything to do with the parent holding company, your Yum brands example is not equivalent.

If I decided to open a store tomorrow and call it Walmart, I'm sure you sure wouldn't tag it as Q483551 either...

You may be interested in the discussion that led up to the split of the aldi brand in NSI (it wasn't me proposing this split): https://github.com/osmlab/name-suggestion-index/pull/5109

I don't know why ID is using an outdated set of brand presets in this case - my assumption is that it isn't updated from NSI on the fly but only periodically. I'm sure you'll see the updated presets in a couple of days.
Until then, I'd respectfully ask you not to change Q41171672 back to Q1250054 - as explained above, Q1250054 is a hodgepodge of two completely different brands that coincidentally happen to have the same name.

Interesting thought on the google/apple pay. They are listed as valid values on the wiki though, and removing them is a loss of information (because, no matter what cc's the store accepts, they may or may not have terminals that are ready & enabled for mobile payments through google pay/apple pay, so I'd argue that removing them without a replacement is a disimprovement).

Just as with the other changeset I commented on earlier - please don't change aldi stores back to Q125054. This is completely ambiguous.
Also you appear to be including the ramp leading to the truck dock (concrete, flat on the ground, not a raised structure) in the building outline now. Is there a reason for this?

Actually, this is not a correction. Please review the aldi brand tagging under https://nsi.guide/index.html?t=brands&k=shop&v=supermarket&tt=aldi
This has recently changed.

Aldi (US) is a fully owned subsidiary of Aldi Sud.
The Q1250054 ("Aldi") brand was being used for subsidiaries of ALDI Sud and ALDI Nord around the world. Nord and Sud are completely separate companies though; with neither owning the other (fully or partially). They're not related.
That being said, the old tagging was imprecise, because it mixed two semantically different brands in one tag value. Your "correction" therefore reintroduced the ambiguity that I had previously fixed.

Apart from that - any particular reason why you removed some of the payment tags?

both the oh and paym opt can be verified on the company's website.

Hi Andy - I saw these, long after they were added, so I decided not to discuss them further. The question that was being asked in the one was related to the usage of a specific tag, which is documented in the wiki.
The other one was related to changeset comments, and very much like the one you posted above, referred to a changeset that touches a single (type of) object in a very small area. _Any_ description in the comment would be 100% redundant of the change itself (what additional information do you gain from "added opening hours" if the change was, well, adding opening hours?). I do agree that changeset comments _can_ be extremely useful, especially when deleting objects (where they explain the "why" rather than the "what") and/or with big change sets (as a summary), but see them as zero-value-add, redundant extra work in cases like this one here specifically.
This feels like
i++; // increment i by 1
-->not technically wrong, and certainly great for comment coverage KPIs, but aside from that, pretty much useless...

review request can be ignored, this was selected inadvertently.