Issue 1:
For me, a increasingly common issue is that I have duplicate translation files. Let me explain with a use case:

Given an entity named 'Article', say you want users to create articles on your website. To make that happen you create a form, and for convenience you set up a convention notation for each of the entity's fields:

# forms.en.yml
article:
fields:
title: Title
summary: Summary
body: Article text
datetime_published: Publish at

And the user sees nicely labeled fields at the form.

Now imagine a CMS for this website, where you want to list the articles. The column names could be the same as above, but since the context is different, you'll want some translations to be different, like this:

# cms.en.yml
article:
fields:
title: Title
summary: Summary
body: Body
datetime_published: Publication date

As your website gets larger and/or the number of entities grow, so do the duplicate translations. There are more use cases to think of where you'd want some sort of inheritance. Something that would work like this:

# domain.en.yml
article:
fields:
title: Title
summary: Summary
body: Body
datetime_published: Publication date

# forms.en.yml
imports:
- { resource: %kernel.root_dir%/../src/Acme/DemoBundle/Resources/translations/domain.en.yml }

article:
fields:
body: Article text
datetime_published: Publish at

# cms.en.yml
imports:
- { resource: %kernel.root_dir%/../src/Acme/DemoBundle/Resources/translations/domain.en.yml }

I have a working proof of concept in a project that's currently running in production. Basically I've extended the regular translation file loader with one that looks for imports in translations, and merges them with the rest of the translation file.

I'm curious if this is something that more people want. Comments and feedback are welcome.

Issue 2:
So, back at square one i guess :)

#20533 reverted the integrity check for accessing services, before the container builder is actually compiled. Making it real tricky, yet convenient. However, it is done for the right reasons, for now.

Where does that leave us? Will it be put back? And what is the alternative/right approach?

Imo. we all agree the check is needed to keep the container trusty, but we lose major flexibility on simple services (ones that can actually be resolved fully at some point before compilation).

Some ideas;

(1) Keep it as is. If this was already decided by now, please close :) Basically saying to the user; with great power, comes great responsibility; do as you like / whatever works for you. Until it breaks that is :))

Deprecate it!

(2) Teach the user to do a different approach in user-land (ie. just initialize a service hardcoded, where needed, when needed). As there will be many tickets about this i guess.

(3) Introduce a 2nd container, compiled and accessible, before compiling the 1st container. The user can configure required services as usual. Ie. what about tagging required services with bootstrap, making the full service available on booting, ie. one config and no duplicate service definitions.

(4) Allow the user to get a service without compiling the current container (ie. clone it, compile it, then get it). However this basically acts the same as option 1 (keeping it as is), whenever it breaks / doesnt work anymore you still need to revise your approach.

(5) Detect which services are safe, and which arent out-of-the-box (the holy grail).

(6) Allow compiler passes to run last with scope on a (sub)compiled version of the container, still allowing to modify the actual container. Doing it in 2 steps, the other way around.