To be clear, the PEP even now supports multiple enviornments (e.g. you can have a lock file that works on multiple OSs). What it doesn’t support is multi-use lock files compared to single-use lock files (which is what I expect you mean, but I don’t want to have a misunderstanding).
I would much rather you have me rip something out of the PEP to accept it at this point than to reject it outright.
So let’s think about those risks. There are risks from it not working as needed and not being used/useless.
In terms of the risk of it not working as needed, the marker expression approach is maximally flexible for the problem it’s trying to solve. @radoering also suggested that he thought it was better than what Poetry was currently doing by overloading extra for their approach to supporting extras. That also suggests the approach solves the goal of making extras work since Poetry uses a similar approach already for this specific need. And if extras work then I don’t see why dependency groups wouldn’t work.
Adding marker expression support could be a feature that doesn’t get used at all or marginally used. That means installers added support for something that doesn’t really get used. It also potentially means slightly more complicated teaching because what’s possible is bigger (single-use vs multi-use), but then again workflow tools already support multi-use lock files and exporting to a requirements.txt file, so users seems to be handling it fine.
Finally, there’s the risk that it simply isn’t enough on its own for multi-use lock files for most cases. @frostming has suggested PDM would switch to relying on the standard if such support landed for extras and dependency groups. So I think it depends on whether you also want Poetry or some other tool to rely on it at the same time as a reason to leave it out (I’m leaving uv off the list due to their workspaces feature).
It’s also a question as to whether a feature that we know is necessary for multi-use lock files should go in now while we are already thinking about it, or only as part of a complete set of features that meet more needs for more tools to fully rely on it. I will say that if we leave out this extras/dependency group support it will be the one part of the packaging standards involving installation that this PEP knowingly doesn’t support.
Let’s think about what it would take for a v2 (since changing the marker syntax and keeping it in packages.marker is not a v1.1 thing to me since you can’t ignore it without installing incorrectly, telling me it’s not a minor update):
- Someone has the motivation to write a PEP (the number of times people have told me they are shocked at my patience with these lock file discussions has been a little worrisome
) - That person figures out the feature set(s) they want added
- They drive the conversation for the PEP (for PEP 751 alone, the post count is at 1,011 posts starting a year ago in Feb, and that’s ignoring side topics and anything related to PEP 665 or discussions even before that about lock files; toss those in and it gets us to 1,714 posts starting 6 years ago, interestingly also in Feb)
- They get enough consensus to get the PEP accepted
- All the tools need to get updated to support v2
Now, hopefully I’ve done all the hard work so the next person tackling this can get it done in less than 6 years and 1.5K posts. 
But I don’t know if what it has taken to get this far will have scared anyone off short of the tools themselves coming forward to do the PEP (then again, I’ve been the one to do this and I’m not directly affiliated with any of the workflow tools).