Can we share some contents of App.config between projects?

Only the "running" app.config is used, but you can go external like marc_s says.

You can also create a .Settings file that's "shared". Go to the "shared" project properties, the Settings tab on the left, create a setting with Application scope, and set the Access Modifier on top to Public. In your other project you can then use ClassLibrary1.Properties.Settings.Default.SettingName to access it. It will be strongly typed, but you may need it at compile time.

Yes - of course. Any configuration section can be "externalized" - e.g.:

<appSettings configSource="AppSettings.DEV.config" />
<connectionStrings configSource="MyConnection.config" />

or

<system.net>
   <mailSettings>
      <smtp configSource="smtp.TEST.config" />

vs.

<system.net>
   <mailSettings>
      <smtp configSource="smtp.PROD.config" />

Any configuration section can be put into a separate file that can be shared between projects - but no configuration section groups, and unfortunately, it's sometimes a bit tricky to know which is which.

Also, in some cases, Visual Studio will complain (using red wavy underlines) that the "configSource" supposedly isn't valid - but it is - it's defined on the ConfigurationSection object in the .NET config system.

UPDATE:
another feature that hardly enough developers seem to know and use is the ability in Visual Studio to add existing files from a different project as a link:

With this, you can add links to files into your local project, and they'll always be kept up to date. Great productivity booster if you need to do some file-level sharing (like for common configuration files or such)!

Try this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings file="PROD.config">
    <add key="common.Currency" value="GBP" />
  </appSettings>
</configuration>

Something I like to do, especially when trying to coordinate ServiceModel elements between libraries and tests is to use configSource to fragment the config in the target library and simply link/copy always the fragments in my test projects.

That way I only maintain in one location.

You could take it one step farther and simply have a common directory in the solution and link the fragments in all projects.