@Pginer-WMF, I have a few questions about this feature:

• If all the items in the group are already marked read, does the button need to gray out? (In case someone suggests it, I would not recommend toggling to Mark group as unread.)
• A small design point: I figured out why there are two check marks in the icon, but I find this confusing. The icon looked to me like a chevron at first; I didn't see it as check marks. My opinion for what it's worth is that one check mark will be cleaner and more clear.
• Do you need to define the colors/display of the button highlight state, or is that standard?
• Should we include a tool-tip for this: "Mark all notifications for this date as read"? Or is it too obvious?

Some time ago I captured some related details in T129460, a more general ticket in this area. Having specific tickets like the current one seems a good idea, so I'm just pointing to T129460 in case some of the details can be incorporated here or in other separate related tickets.

Regarding the specific questions:

In T132738#2208928, @jmatazzoni wrote:

@Pginer-WMF, I have a few questions about this feature:
If all the items in the group are already marked read, does the button need to gray out? (In case someone suggests it, I would not recommend toggling to Mark group as unread.)

Yes the button should become disabled if all the items in a group are read.

The "mark group as read" action should affect only those elements displayed in the group. For example, if I have 10 notifications today, but due to filters only 5 of them are be displayed, the "mark group as read" will only affect those, and will be enabled (or not) based on the state of those 5 notifications.

A small design point: I figured out why there are two check marks in the icon, but I find this confusing. The icon looked to me like a chevron at first; I didn't see it as check marks. My opinion for what it's worth is that one check mark will be cleaner and more clear.

For this action we want to the ideas of "completion" (marking items as read/done) and "propagation" (we are acting on several different items in one go). The tick mark is intended to support the first idea, and duplicating it is intended to support the second one. The ongoing research on the Notification page (T124416) where the metaphor is used may provide us with more information on how well that works.

I agree that the idea of completion is the main one, but I'd like to try to support both in this context if possible. For example, Google Inbox uses a tick mark on top of a list in a similar context. Although it is also true that in our case, the presence of a label to give clarity could complement well the meaning of the action even if a single tick mark was used.

Do you need to define the colors/display of the button highlight state, or is that standard?

It's standard. Buttons are standardised widgets, we can just use the OOUI component and they will reflect the design considerations for buttons. You can see the OOUI demo and the design spec for them.

Should we include a tool-tip for this: "Mark all notifications for this date as read"? Or is it too obvious?

I'd not oppose tooltips in a situation where an action gets propagated to confirm the user expectations. However, I'd do that only if we can provide added value compared to what the label already says. So I'd start without tooltips and if we identify users experiencing some friction or doubt about the action, use the tooltips to clarify it.

Note also that when any kind of filtering or pagination is available, the action won't mark as read all notifications for the date but only those items displayed in the group. The use of "group" was intentional to work in that context.

Checked in betalabs - all specs are in place with small deviation from

When the user is filtering results to view only Unread, clicking the Mark group as > read button will cause the group to a) get marked as read and b) disappear.

When the user is viewing only Unread, clicking the Mark group as read button will cause the group to a) get marked as read but NOT to b) disappear. The page requires manual refreshing. -- As per @Pginer-WMF suggestion split it to a separate issue T136891: Special:Notifications: the filtered 'Unread' page needs to be refreshed after messages were marked as read.
Also, when 'Read' or 'Unread' pages get refreshed manually, a user will be redirected to the 'All' messages page - a known issue.