Bug is repeatable if have a table, which references original one, and use option --alter-foreign-keys-method=drop_swap:

sveta@Thinkie:~/issues/100474$ ~/src/percona-toolkit/bin/pt-online-schema-change --user root --execute --no-check-replication-filters --alter-foreign-keys-method=auto --critical-load Threads_running=400 --alter "ADD CREATED_BY_ORGANISATION_ID INT AFTER CREATED_BY_CUSTOMER_PROFILE_ID, ADD FOREIGN KEY (CREATED_BY_ORGANISATION_ID) REFERENCES SmileDB.organisation (ORGANISATION_ID) ON UPDATE RESTRICT ON DELETE RESTRICT" --alter-foreign-keys-method=drop_swap D=SmileDB,t=product_instance,h=127.0.0.1,P=13001
No slaves found.  See --recursion-method if host Thinkie has slaves.
Not checking slave lag because no slaves were found and --check-slave-lag was not specified.
Operation, tries, wait:
  analyze_table, 10, 1
  copy_rows, 10, 0.25
  create_triggers, 10, 1
  drop_triggers, 10, 1
  swap_tables, 10, 1
  update_foreign_keys, 10, 1
Child tables:
  `SmileDB`.`service_instance` (approx. 1 rows)
Will use the drop_swap method to update foreign keys.
Altering `SmileDB`.`product_instance`...
Creating new table...
Created new table SmileDB._product_instance_new OK.
Altering new table...
Altered `SmileDB`.`_product_instance_new` OK.
2016-07-23T00:55:20 Creating triggers...
2016-07-23T00:55:20 Created triggers OK.
2016-07-23T00:55:20 Copying approximately 1 rows...
2016-07-23T00:55:20 Copied rows OK.
2016-07-23T00:55:20 Drop-swapping tables...
2016-07-23T00:55:20 Analyzing new table...
2016-07-23T00:55:21 Dropping triggers...
2016-07-23T00:55:21 Dropped triggers OK.
2016-07-23T00:55:21 Dropping new table...
2016-07-23T00:55:21 Dropped new table OK.
Altered `SmileDB`.`product_instance` but there were errors or warnings.
Error updating foreign key constraints: 2016-07-23T00:55:21 DBD::mysql::db do failed: Table './SmileDB/product_instance' already exists [for Statement "RENAME TABLE `SmileDB`.`_product_instance_new` TO `SmileDB`.`product_instance`"] at /home/sveta/src/percona-toolkit/bin/pt-online-schema-change line 10507.

veta@Thinkie:~/mysql_packages/Percona-Server-5.6.21-rel70.1-698.Linux.x86_64/mysql-test$ mysqlmtr -P13001 SmileDB 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 18
Server version: 5.6.21-70.1-log Percona Server (GPL), Release 70.1, Revision 698

Copyright (c) 2009-2014 Percona LLC and/or its affiliates
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show tables;
+-----------------------+
| Tables_in_SmileDB     |
+-----------------------+
| customer_profile      |
| organisation          |
| product_specification |
| service_instance      |
+-----------------------+
4 rows in set (0,00 sec)

Manually adding option --alter-foreign-keys-method=drop_swap  is valid test method, because in the tool's output in the initial description we see:

Determining the method to update foreign keys...
2016-06-29T18:33:59 `SmileDB`.`service_instance`: too many rows: 74456; must use drop_swap
2016-06-29T18:33:59 Drop-swapping tables...

I set status of this report to "Confirmed", but this is actually feature request, because such behavior of drop_swap described at https://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html#cmdoption-pt-online-schema-change--alter-foreign-keys-method:

----<q>----
drop_swap

    Disable foreign key checks (FOREIGN_KEY_CHECKS=0), then drop the original table before renaming the new table into its place. This is different from the normal method of swapping the old and new table, which uses an atomic RENAME that is undetectable to client applications.

    This method is faster and does not block, but it is riskier for two reasons. First, for a short time between dropping the original table and renaming the temporary table, the table to be altered simply does not exist, and queries against it will result in an error. Secondly, if there is an error and the new table cannot be renamed into the place of the old one, then it is too late to abort, because the old table is gone permanently.

    This method forces --no-swap-tables and --no-drop-old-table.
----</q>----

Feature request: specify option (--auto=rebuild-constraints,none or --auto=none) which fails back from rebuild_constraints to none for those who wants reasonably fast swap, but without risk of loosing data. Or allow drop_swap to work with option --no-drop-new-table: do not ignore all warnings and if warnings exist rename new table back.