Non-exclusive members of the development team

Very often, deep and pervasive organizational change is necessary for Scrum to be implemented effectively.

Having people working in several Dev Teams should be avoided. 

In Scrum it is essential that you keep it simple, for example with meetings. Best to have them same time, same place. If you have several teams without intersections, they can easily have their meetings at the same time or overlapping. If you have at least one in several teams, have fun coordinating meetings.

Another point of course, how much percent is the developer working for which team, is that always considered in Planning? What if one team has something urgent that he shall take over during the sprint? 

As for externals, I don't see an issue. Neither the PO nor the SM will give direct orders. Scrum Team is self organizing, as part of the team the externals are participating in organizing the Scrum Team. And as for DoD, participation in meetings and so on, have your company put that in the contracts with the externals to follow.

Going to start with something I always say.  There is no such thing as a best practice, just a whole lot of good ideas.  I say that because I seriously doubt that anyone can tell you the best way to hande this.  

I will say that your organization doesn't seem to have committed to Scrum.  The type of environment you just described is something I lived with for a long time in the old world of Gantt Chart managed projects.  Those days made it possible for individuals to work on multiple projects because you could schedule their time accordingly.  In an agile world it is much more difficult to do this type of activity. Focus is one of the Scrum Values but this organizational model leads to people being unfocused on their work since they are doing work for multiple purposes. 

Ok, putting away the soapbox.  My suggestion is that you make the impact of this organizational model very visible every chance you get.  Point out where there are impediments due to an individual being focused on work for another team.  Indicate when something is being delayed while the team waits on something from an external entity.  Making these impediments visible can help the organization to understand that organizational change is necessary.  But very careful that you are not placing blame, just state it as a fact.  AND you will have to be just as transparent when someone that is dedicated to your project causes some kind of impediment.  If not, you will just be seen as someone complaining.  Courage is the Scrum Value in play in this case. 

My worst nightmare: external dependencies which are not known when starting an action

As for that one, the best way to deal with those is to be more diligent in your refinement activities.  You may always have these but learn from the occassions where they occur.  Retrospect on those times and look for ways to anticipate them.  Also learn how to react to them when they do occur.  Remember you are making your Sprint plans based upon the information available to you at the time of planning.  If you can find ways of making more information available, then you should take advantage. 

Another good idea I will offer is that you can not expect to fix all of those things at once.  Focus on the one that causes the most difficulty and experiment with changes to find something that does provide relief.  Then focus on a second one.  Just as incremental delivery of product helps to arrive at the correct product in the end, so do incremental changes in behavior. 

Just to clarify

5) My worst nightmare: external dependencies which are not known when starting an action

Why?