Another report of the problem here http://forum.joomla.org/viewtopic.php?f=707&t=861997#p3230172.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4836.

Further examination shows ... The #__content_types is created from 3.1.0.sql ... it is after that when it gets to 3.2.0.sql that it appears to fail somewhere after line 18 but before line 23 of 3.2.0.sql.

Lines 12 to 17 insert the last 5 records of the #__content_types Table ... those show in the database after failed update

Lines 22 to 29 insert 7 records into #__extensions ... but those do not show in the database

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4836.

I have a theory on why these duplicate entries happens. For me it happened when I did:
1. Upgrade joomla 2.5 to joomla 3
2. Restore joomla 2.5 backup (using akeeba backup)
3. Upgrade to joomla 3 again

When I restore joomla 2.5 some tables from joomla 3 are not dropped so on next upgrade the new joomla 3 tables already exist and can't be created.

A restore of a backup should occur on a clean environment. No (joomla related)files left in the folder, no tables with that prefix in the database!

Restoring a backup of an old version on top of a newer version would not
surprisingly cause issues.
On 15 Nov 2014 12:23, "sovainfo" notifications@github.com wrote:

A restore of a backup should occur on a clean environment. No (joomla
related)files left in the folder, no tables with that prefix in the
database!

—
Reply to this email directly or view it on GitHub
#4836 (comment).

That would depend on how old the 3rd party extensions. Some of 2.5/3,x compatible extensions use the same zip to install but install different files depending on the version of Joomla they are being installed to.

It would also depend on the age of the backup ... or to be more precise the age of the 3rd party extension files in the backup. If the 3rd party extensions were updated before the Joomla update but the backup was made before 3rd party extensions were updated ... then the older 3rd party extensions could cause problems.

Further investigation of the site referred to in the forum thread for this tracker ... showed that:

a. At least one 3rd party extension was 2.5/3.x compatible but after Joomla update the 3rd party extension the extension had to be reinstalled using the same zip file used to install it into 2.5 ... because the plugin gave a warning that extension was using the 2.5 files.

b. Several 3rd party extensions were not up to date

c. The Template overrides of the custom Template contained code that did not work with 3.x

Since opening this report I have discovered that
1. Uninstalling the 3rd party extensions that do not have 3.x compatible counterparts and setting the default Template to beez
2. Deleting the folders/files and replacing with the Joomla 3.3.6 full package
3. Installing Joomla 3.3.6 to and empty database then installing the 3rd party extensions to the fresh install.
4. Editing the configuration.php to connect to the original database.
Allows access to /administrator >>> Extensions >>> Extension Manager >>> Database ... the 'Fix' button then completes the update.

Conclusion
Failed Joomla 2.5 to 3.x upgrades is (almost) certainly caused by files in 3rd party extensions.

So, this can be closed then! Not doing the right things can mess up Joomla. Nothing to do with Joomla, it is not designed to be unbreakable no matter what you do to it.
Replacing files and manipulating data outside of backend and you are on your own. Not considered a Joomla problem because you messed up!

imho should be closed as not Joomla core

I agree that doesn't sound like a core issue. Closing it.

I agree with the « Joomla is not designed to be unbreakable no matter what you do to it. ».
However, a little patch of 3.1.0.sql with

    DROP TABLE IF EXISTS `#__content_types`;

or

    TRUNCATE `#__content_types`;

before creating the table or populating it could help a lot of people.
Of course this kind of patch would be needed for all new tables.

Thanks anyway for this issue that helped me ;-)

Disagree with the TRUNCATE, don't mind a DELETE where id = range of rows to be inserted.