The main changes accross the system would be. a) Having a language field for all the translatable objects that can be just ignored or: b) Joining simple language conditions when you want 'multilingual features enabled', that would be 'enabling i18n module'
Yep, so the support is there whether you use it or not. I had a bunch of counter-arguments against your points, but I erased them all because I can summarize with this. 1. The i18n module doesn't add multi-lingual node support. It adds a language flags to a node. This is an important distiction because you're still building two sites, they're just mashed together into one through complexity. 2. Using a language in the URL, "namespace", is a great approach, but it's just one intuitive way to designate the language. Totally separate issue from #1. 3. If nodes are not truely multi-lingual, it is better to build a site for each language. This will accomplish the same thing but in a simplier fashion. This starts falling apart if you're building anything bigger than a brocure site. See: http://www.ndp.ca, drupal, brochure site, multi-lingual, yet very intuitive. Navigate to a node, and click the 'francais' link at top... that's how it should work. 4. FYI: I'm not hating on the i18n module, in fact, much props for your work. Considering 4.7's i18n limitations, I just can't see any benefits of using it over building a site for each language.
If we provide some generic mechanism in core for handling I.e. multilingual nodes, the contributed modules don't need to worry at all about it. Same for whatever other object -menus, blocks, etc..
Agreed, +1 from me. Ben.