thanks for sharing your thoughts/concerns!
I have expressed elsewhere in this thread that I am a proponent of
hiring more development mentors rather than generic developers; so it
is hard for me to get excited about this proposal.
Also I forgot to answer Heiko elsewhere that his idea of graphics
designer / website developer in one person sounds reasonably positive
I believe that not being excited about the idea is totally valid. Let me explicitly mention that I'm also open to other suggestions and how they would help to move forward with the issues that were brought up.
As mentioned in my reply to Michael  however, I'm currently not so convinced whether "plain" development mentors would have the same chance of providing success when it comes to progress in *specific* areas (which does not at all mean I'm against having more mentors in general).
Having said that, maybe we can get a bit more constructive even in this
discussion about hypothetical possibility of hiring generic
developers; so what about this:
Michael, please - would you be willing to further your (and Sophie's)
idea in form of a document that can be discussed as a whole,
particularly how the details together fit the TDF mission?
While I wouldn't say I came up with the general idea, I'm happy to contribute my thoughts in case the decision in today's BoD meeting is that it's worth having such a document for further discussion.
I don't think I'll be able to do that just by myself (and there are certainly people who know better "how TDF works"), but I'm definitely willing to be part of a group that creates such a document.
I'll reply with some first thoughts to your questions below for further discussion without claiming those are "the ultimate answers". In any case, I'm happy to learn and hear other opinions.
I myself would be interested in the following questions; do you think
you can cover them some way, please?
* How to frame the hiring process - where developers should have a say
in it, without being accused of CoI?
I'm not familiar with the TDF hiring process. Is it so that the BoD is involved here and ultimately takes the decision?
If so, I don't see any lack of competent developers in the new BoD to cover that perspective.
In my previous email I wrote that I personally wouldn't assume a CoI in case the tasks of TDF developers were set accordingly, and it definitely sounds reasonably to me for all BoD members to have a say.
I'm not too familiar with the CoI policy, but as I understand it, the remaining BoD decides whether or not a CoI exists for a specific member.
So would that point be addressed in case all BoD members agreed that all BoD members can have a say in the vote?
(Whether or not all BoD members agree here is obviously a question I cannot answer.)
* How to make it quick, so that the potential hires are still available
once TDF decides for this or that candidate?
I'm not familiar with the TDF hiring process, but I would assume the answer here should be unspecific to the specific role of the person being hired and would arise just the same in case of hiring more development mentors instead.
* How to get the developers up-to-speed or mentor them once they are
That probably depends on whether the hired developers are completely new to the project or have participated previously.
In general, I'd go with the established approach that is used for non-TDF contributors as well (have them learn by doing).
* Also how to task them, how to day-to-day manage them, [...]
(splitting this here, second part of the sentence below)
That's up to discussion, my initial idea outlined in my previous email  would be to involve ESC and/or BoD when it comes to larger topics to be worked on.
I personally wouldn't see a need to control every single small item that they work on but give them some "freedom" to work on what they identify along the way as they work on larger topics.
But if there's a concern that would be problematic, more micro-management from BoD (or some representative that has been assigned by the BoD to take care) would of course be possible as well (like assigning specific Bugzilla tickets to work on or first discuss the thoughts they come up while doing their other work).
[...] and how to make
sure they are progressing at a reasonable pace?
* What to do if they get stuck, and there is nobody in the community
who can help them?
I think those are questions that every developer is facing. My personal perception is that developers are working together well and there has so far basically always been help from others when somebody asks for specific help at a certain point (via developer mailing list or IRC).
* How to detect they are not performing, and just consume the donors'
As above for the hiring process: I think the BoD has experienced developers who should be able to judge that. (And I think otherwise e.g. the team could help assess that, e.g. in the hypothetical case a future BoD didn't have any developers; there are people in the TDF team whom I'd trust to have sufficient insight into development to do so).
* How to make sure they don't compete with other open source projects,
or the ecosystem companies?
* How to make sure they are not misused by (any, not only ecosystem)
companies to fix bugs for them or for their customers? [Particularly
companies disguised by @gmail or so addresses in bugzilla.]
I think that's a matter of setting the right tasks (or, on a different level, having the right processes to decide on tasks), as outlined above and in my previous email. 
* On the other hand - how to make it possible to cherry-pick fixes or
features into the release branches of ecosystem companies without
the risk of being accused of misusing the previous point?
To be honest, I don't see any risk here. However, in case there are concerns, the answer would probably be the same as above to ensure they are working on the "right" tasks in the first place. (In a free and open source project, it's just fine to reuse the work of others, and the case of cherry-picking other contributors' commits to vendor branches you describe already happens in LO all the time and I don't see a relevant difference for the case a certain developer is working for TDF.)
* Should there be a mechanism for the ecosystem companies to flag a bug
"this is what I'm working on for a customer - please don't touch"?
One simple way that comes to my mind would be to just assign the bug in Bugzilla.
But in case there's actually a specific need to establish a different mechanism for specific cases, why not?
* With my pet idea of development mentors rather than generic
developers in mind - should they be mentoring too, and if yes, how
to prioritize vs. the actual development?
That's up to discussion. One potential idea mentioned in my reply to Michael  that would IMHO fit well with the idea of advancing in specific areas would be to give them responsibility over a certain area to improve. In case other people are interested in working on that area, mentoring them should IMHO have a higher priority at that point in time since it's good to get others involved.
* How to avoid growing a group-think in the internal developers
group that there is no need for the ecosystem companies, or even
for the community as a whole? [As explained elsewhere; as much as
it sounds strange - TDF is a subset of the community, not the other
I completely agree with the "TDF is a subset of the community" part.
The described scenario would indeed be very unfortunate, but I don't see a risk here, in particular for the case where TDF employs a small amount of developer with the main focus to take care of neglected areas. (It might be more relevant in case employing a large amount of developers were discussed.)
In general, having the right atmosphere of working together in the community is probably the most important point here. At least in my personal experience so far, I did not at all have the impression of destructive competition among developers, but rather people working together nicely and helping each other, and I don't see why adding a few TDF developers to the mix would change that.
* How to avoid TDF internal developers to feel (or worse, to be)
"more equal" than the rest of the community - particularly when
there is no 1/3 rule for them, direct access to release engineering
and admins (their colleagues), etc.?
The answer here is probably mostly the same as the previous one.
I currently don't see any reason to not have the same standard processes of contribution for them that all other developers also use.
Considering your reply to Andreas , I guess I'm missing the personal "OpenOffice.org/Oracle experience" to be able to better imagine such a situation, but I see no reason for assuming the same could happen with LibreOffice again.
I am sure this list is not exhaustive, and suppose others will
contribute, but hope it is a start.
Thanks again! My attempt to provide potential answers is certainly also not exhaustive and I'm happy to hear other opinions on that.