Migration creates 2 columns when related model name contains number

[cd-slash]

• Laravel Version: 11.21.0
• PHP Version: 8.3
• Blueprint Version: 2.10.0
• Platform: Mac

Issue:

When creating a model with a specified column name for a relationship, a second column with a slightly different name is created if the related model name contains a number. For example:

Location:
    name: string nullable
    coordinate_id: id nullable
    what_3_words_id: id nullable
    google_plus_code_id: id nullable
    relationships:
      belongsTo: Coordinate, What3Words, GooglePlusCode
      belongsToMany: Place, Boundary

What3Words:
    word_1: string
    word_2: string
    word_3: string
    relationships:
      belongsTo: Location

results in the following migration being created:

Schema::create('locations', function (Blueprint $table) {
    $table->id();
    $table->string('name')->nullable();
    $table->foreignId('coordinate_id')->nullable();
    $table->foreignId('what_3_words_id')->nullable();
    $table->foreignId('google_plus_code_id')->nullable();
    $table->foreignId('what3_words_id');
    $table->timestamps();
});

Note the two different columns, what3_words_id derived from the relationship, and what_3_words_id as specified manually in the blueprint.

I have not been able to determine what the proper convention should be for model names that contain numbers, but have styled this model name to match how the company itself styles their location IDs (see What3Words).

I can of course work around this by spelling out the number (i.e. WhatThreeWords) but it seems to me like a number in the middle of a model name should be treated as a word boundary rather than a continuation of the prior word, while consecutive numbers should be considered a single word for the purposes of column naming. Open to alternative views.

draft.yaml: shown above

[jasonmccreary]

I'd have to dive down into core to see what they assume the name to be. But I would imagine it's singular, snake model name - which is what3_words. I don't see a bug here as the manual column name is at the users discretion. Unless the model code generated didn't set this as the foreign key in the relationship.