There should be two files attached, models-0001.py and models-0002.py.  Copy
them into an application directory x, and symlink one or the other to generate
the initial and changed migrations.  The comments in those classes may reflect
an early, flawed understanding of the bugs, so don't place too much faith in
what they claim to test.  Not going to change anything there now...

with models-0001, no migrations:

  Creating tables...
    Creating table x_ring
    Creating table x_one
    Creating table x_twosies
    Creating table x_three_ring
    Creating table x_three
    Creating table x_four_ring
    Creating table x_four

Okay, that's all correct!  Let's clear everything out and verify with models-0002:

  Creating tables...
    Creating table x_ring
    Creating table x_one
    Creating table x_twosies
    Creating table x_three_ring
    Creating table x_three
    Creating table x_four_ringsie
    Creating table x_four

x_three and x_four are never a problem, so summarizing the above and what happens
when the tables are built by migrations (models-0001 first, then models-0002 for
the second migration):

Source says				non-migration		migration 0001		migration 0002	migration 0002
						creates				creates				(all "no")		sensible yeses

x_one					x_one				x_one				x_one			x_onsies ???

x_twosies				x_twosies			x_twosies			x_twosies		x_twosies

x_three_ring			x_three_ring		x_three_ring		x_three_ring	x_three_ringsies

x_four_ring (#1)		x_four_ring			x_four_ringsie !

x_four_ringsies (#2)	x_four_ringsies							x_four_ringsies	x_four_ringsies

Migration 0002 is so full of fail that I need to present it differently.  There are
choices to be made, y'see.  So if I interpret it literally, the true answers are
all "no" and it looks like this:

Did you rename the x.Two model to Onesie? [y/N] n
Did you rename the x.One model to Onesie? [y/N] n
Did you rename the x.Two model to Twosies? [y/N] n
Did you rename the x.One model to Twosies? [y/N] n
Did you rename four.ringsie to four.ring (a ManyToManyField)? [y/N] n
Did you rename three.ring to three.ringsies (a ManyToManyField)? [y/N] n
Migrations for 'x':
  0002_auto_20140726_0149.py:
    - Create model Onesie
    - Create model Twosies
    - Delete model One
    - Delete model Two
    - Add field ring to four
    - Add field ringsies to three
    - Remove field ringsie from four
    - Remove field ring from three

Oddly, applying this does NOT make x_onesies - see above (all "no").  But trying
to rewind to 0001 fails: table "x_three_ring" already exists, so clearly things
are screwed up.

Clearing it all out,  sqlmigrate 0002  gives this marvellous nonsense:

CREATE TABLE "x_one" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(40) NOT  NULL);
CREATE TABLE "x_twosies" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(40) NOT NULL);
DROP TABLE "x_one";
DROP TABLE "x_twosies";
CREATE TABLE "x_four_ring" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "four_id" integer NOT NULL REFERENCES "x_four" ("id"), "ring_id" integer NOT NULL REFERENCES "x_ring" ("id"), UNIQUE ("four_id", "ring_id"));
CREATE TABLE "x_three_ringsies" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "three_id" integer NOT NULL REFERENCES "x_three" ("id"), "ring_id" integer NOT NULL REFERENCES "x_ring" ("id"), UNIQUE ("three_id", "ring_id"));
DROP TABLE "x_four_ringsie";
DROP TABLE "x_three_ring";
CREATE INDEX x_four_ring_d1a8cfcf ON "x_four_ring" ("four_id");
CREATE INDEX x_four_ring_66194dd2 ON "x_four_ring" ("ring_id");
CREATE INDEX x_three_ringsies_375bdf5f ON "x_three_ringsies" ("three_id");
CREATE INDEX x_three_ringsies_66194dd2 ON "x_three_ringsies" ("ring_id");

And at this point I've added what my notes from an earlier test showed when answering
yes or no as was sensible (viz., correct, except for an incorrect change of table name).
All these rubbish errors have me too out of sorts to regenerate it all and start over to
verify that.

It seems clear that there's a problem in the model "parsing", and IMO the earlier patch
that closed #22975 is a bandaid over the problem (and maybe doesn't work in all cases,
if that x_onesies I recorded was really there).  In the M2M intermediary table it's
clear that it simply ignores the db_table that Django itself resolves altogether; I
suspect that same sore of blindness is the actual cause of the other bug as well.  I
have not gone spelunking in the new migrations code nearly enough to demonstrate that
myself.  ;-/