I honestly think we just need to have light and dark modes built in. If you want to modify the dark theme a bit, go ahead, but since the original dev knew the background should be dark and the foreground light, it should be OK.
The problem is when people implicitly assume a light theme, but then use a dark one.
If we could "tag" a theme as light or dark, a lot of this problem would go away.
I think you're onto something, but I don't think it's as simple as just having a "light theme" and a "dark theme".
I think that if we're going to have toolkits that support custom, nested widgets, those widgets need to be designed to support the context they are in. There will always arise situations where normally-light widgets need to appear on a dark background, or vice versa. The nested path bar example is exactly this - it's a widget that supports a single context (light background), but is having two contexts forced on it by leaky style cascades (light text, but also light background).
How about we bake the concept of "light" and "dark" into the widgets themselves and take advantage of the cascading nature to switch the theme of a widget depending on the context it is in.
Realistically though, GNOME 3 was rather short-sighted when it came to themes. Windows 95 showed us the way 24 years ago: you can change the colours of anything you want. You can tweak the size of most things. You can change the fonts. You can change the icons. Simple API that gets applied on top of an existing theme. Expand this for 2019 with dark and light variants for each theme, and I bet we'd satisfy almost all users.
