We can't really qualify that as a bug. Default sets the behaviour for the entire app, and isn't really meant to be used "by default" (haha).
But it is a regression of v2 from an integrator's perspective: until now, it was okay to use default as the scope of your settings. With the v2 release, this will break the backoffice without the integrator doing anything. Fortunately, it is a v2, meaning that we are allowed BC breaks. But since it touches to day-to-day integration, I think we must be pro-active on it.
Our options, sorted:
1. Document it: the site group, or siteaccess, should be used for frontend sites. Default is meant for extensions, as it sets the default behaviour of a feature for the entire system.
2. Warn people, starting from v1: log a deprecation warning clearly explaining what must be changed
3. On v2, think of ways to silently handle that. We could for instance detect view configurations on default, and change the scope to the site group. We could also warn more brutally during compilation. The main challenge here is to distinguish legitimate usage of default from misusages.
4. Do a spike using the design engine & the @ezdesign operator for everything. The admin-ui would use an "admin" siteaccess. Default templates (fields, views, repository forms, etc) would be part of the "standard' design. Discussions with integrators have shown that this was a very, very popular aspect of the legacy's template system.