After SP1 the problem with Violation of Primary Key Constraint Error returned when we tried to run the incremental job. The previous Hot fix (936867) from Microsoft for this seems to have been overwritten by the SP.

We got this error:
Content deployment job 'Incremental Content Deployment' failed.The exception thrown was 'System.Data.SqlClient.SqlException' : 'Violation of PRIMARY KEY constraint 'PK__#ExportObjects____4F86F15A'. Cannot insert duplicate key in object 'dbo.#ExportObjects'. The statement has been terminated.' 

To solve this we turned off minor versions on both the Style Library and the Site Collection Images library.

But it still did now work so I removed all previous versions of the files that had a version above 1.0 and that did the trick. (I created a flat view that only displayed the items with version greater than 1.0).

Thanks to the Hungarian SharePoint Geek that pointed me in the correct direction:
http://www.sharepointblogs.com/pholpar/archive/2007/05/22/primary-key-violation-when-using-the-spexport-object.aspx

Updated: The problem came back so I created a feature with a reciever that turned off the Parallell Worklow, Approval, Versioning and in and out checking of the libraries Images and Documents. Then a made sure that this feature was turned on in all my site templates and then I used a small console application to turn it on on all sites that were created earlier. That made the trick ...

If you are using the SPUrl expression prefix you can use the ~language to get the language-code for the site.

Example:
    <link id="LanguageCss" rel="stylesheet" type="text/css" href="<% $SPUrl:~SiteCollection/Style Library/TheCompany/~language/LanguageSpecificStyle.css%>" runat="server" />
Will give you something like this when evaluated:
    <link id="ctl00_LanguageCss" rel="stylesheet" type="text/css" href="/sites/theSite/Style Library/TheCompany/en-US/Styles/LanguageSpecificStyle-main.css" />

If you want to use a audience field on a pagelayout you can use the example below in your aspx. 

...
<%@ Register tagprefix="FieldTypes" namespace="Microsoft.Office.Server.WebControls.FieldTypes" assembly="Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
...
<asp:Content contentplaceholderid="PlaceHolderMain" runat="server">
...
    <PublishingWebControls:editmodepanel runat="server" id="editmodepanel">
...
                    <FieldTypes:SPFieldTargetToControl runat="server" FieldName="Audience" AudienceTypes="GlobalAudience" />
...
    </PublishingWebControls:editmodepanel>
...
</asp:content>

In various onet.xml you often see the two publishing features with the following property SimplePublishing set to true.

The advantage with this is that you don't have to go through the Approval workflow for every page that is going to be published. The disadvantage is that you lose the ability to schedule pages for later publishing and how long they should be published.

The solution to get the best of both worlds (scheduling but no approval workflow) is to change the site definition to this instead:
<SiteFeatures>
        ...
        <Feature ID="AEBC918D-B20F-4A11-A1DB-9ED84D79C87E">
          <!-- PublishingResources -->
          <Properties xmlns="http://schemas.microsoft.com/sharepoint/">
            <Property Key="AllowRss" Value="false"/>
            <Property Key="SimplePublishing" Value="false" />
          </Properties>
        </Feature>
        ....
</SiteFeatures>
<WebFeatures>
        <Feature ID="22A9EF51-737B-4FF2-9346-694633FE4416">
          <Properties xmlns="http://schemas.microsoft.com/sharepoint/">
            ...
            <Property Key="SimplePublishing" Value="false" />
            <Property Key="EnableApprovalWorkflowOnPages" value="false" />
          </Properties>
        </Feature>
        ...
</WebFeatures>

Have fun,
Niklas