Why Does Laravel 5.8 Migration Not Work Without Changing The Table Name?

I have the following table schema;

Schema::create('users', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('email');
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->string('account_type')->default('1,1,0');
            $table->string('theme')->default('light');
            $table->string('unique_id')->nullable();
            $table->string('avatar')->nullable();
            $table->rememberToken();
            $table->timestamps();
            $table->unsignedBigInteger('plan_id');
            $table->foreign('plan_id')->references('id')->on('plans');
            $table->unique('email');
        });

When I run migrate, it fails with the error:

errno: 150 "Foreign key constraint is incorrectly formed"

If I remove the foreign key, it still doesn't work.

It does work, if I change the table name from 'users' to anything else, but will then fail if I run it again (requiring the table name to be changed again).

Here is the schema for the table that is referenced, this migration also runs before the users migration.

Schema::create('plans', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name')->unique();
            $table->float('cost', 8, 2)->nullable();
            $table->integer('free_trial');
            $table->string('renewal_rate');
            $table->string('features');
            $table->string('stripe_plan');
            $table->boolean('featured')->default(true);
            $table->string('permission');
            $table->timestamps();
        });

Having spent days trying to resolve this, everyone seems to point to the bigIncrements/unsignedBigIncrements being the same along with typos in the column names. I don't seem to have that issue..

It seems to be an issue with XAMPP, reinstalling XAMPP has fixed the issue, I'm not sure of the cause, it has also reduced the time taken to migrate from around 5-10 seconds per table to 0.1-0.6 per table.