Александр Талалаев

Это классическая проблема N+1 запроса: при обращении к БД делаем лишних N запросов, хотя можно обойтись одним сразу.
В Laravel она возникает из-за ленивой загрузки отношений по умолчанию, те при выборке данных модели из БД, отношения не выбираются. Чтобы этого избежать используется with (и его "друзья").

//Выбрали все посты, данные только по ним
$posts = Post::orderBy('created_at', 'desc')->limit(20)->get();
foreach( $posts as $post )
{
//обращение к БД за данными по отношению user
  print_r($post->user);
}

//Два запроса
// 1.Выбрали все посты, данные только по ним
// 2. ПО айдишкам из данных таблицы постов, выбрали сразу все нужные из user
$posts = Post::orderBy('created_at', 'desc')->with('user')->limit(20)->get();
foreach( $posts as $post )
{
//обращение к БД за данными по отношению user НЕ происходит, данные уже есть и скомпонованы
  print_r($post->user);
}

Советую читать документацию,
так же самые распространенные подводные камни с N+1 https://laravel-news.com/laravel-n1-query-problems

Такая ошибка, при верном коде в бекэнде, обычно появляется если запрос идёт из формы(не важно напрямую или аякс запрос) и методе в форме/аякс запросе вы указали метод "DELETE". Он не поддерживается, нужно ставить метод POST, а в данных при запросе передавать "_method:"DELETE"". Поэтому если из запрос из условного "HTML"/браузера то тип запроса POST, с пометкой в данных что это DELETE. (через добавления в форму поля _method со значением DELETE или добавление в объект в данные _method:"DELETE")

axios.post(`/api/anketa/${id}`, {_method: 'delete'})
                .then(res => {
                    this.getpoluhenie();

А из сторонних клиентов, которые поддерживают метод DELETE (сам клиент) так делать не нужно, можно использовать метод DELETE напрямую.

Почему костыльно?
Почитайте про sometimes - здесь мы говорим что валидировать если поле есть в теле запроса
Ну и про усложнённую логику валидации.
Скорее всего вам просто нужно вместо nullable, сделать sometimes и тогда вы будете валидировать поле, только если оно есть в запросе.

Используйте pluck или only, что лучше подходит в вашем контексте

У вас есть два пути, у которых есть общая часть это данные о языке оригинале (правда не без подводных камней, есть двуязычные, но пока опустим).
Первый вариант, вы в Song храните id песни, язык оригинала(пусть сейчас условно строка, 'en' или 'ru', но возможно id языка и связь с другой таблицей), ну и другие мета данные, айди автора, группы и прочее.
а в отдельной таблице SongTranslations вы храните уже id, id песни, язык(или его id), название, текст.
Второй вариант, мне он немного больше нравится в самой таблице Song сделать больше текстовое/json поле где мы будем хранить переводы песни в виде json (снова таки возможно он будет сложнее)

{
[
{'en': { 
title: 'название на английском',
lyric: 'текст на английском'
}
},
{'ru': { 
title: 'название на русском,
lyric: 'текст на русском'
}
}
]
}

Ну идею вы поняли

Насчёт конкретно подхода о котором вы говорите не скажу, скорее всего это плохая идея. Видел пару примеров несколько лет назад, бОльшая часть этих модульных подходов было нечто среднее между недомикросервисного подохода, с примесью разработки composer пакетов и элементами (концептуальными) плагинов wordpress.
Или другой подход где "модули" laravel разделялись пространством имен и особой структурой, с некоторыми костылями для поддержки разделения кода. Этот подход формально лучше, но по факту обычное не нужное усложнение проекта. Но если вам интересно, можете изучить https://github.com/nWidart/laravel-modules
Но как по мне, если уж и заморачиваться в подобном плане, то скорее наоборот отвязкой максимальной ядра приложения от любого фреймворка framework-agnostic подход.
А так... Главный принцип, в целом кстати во многом пересекается с принципами микро сервисной архитектуры:
есть определенная часть/логика приложения, которая может выполнять свою функцию независимо, которую могут писать разработчики независимо, можно выделить в отдельный пакет. Например, вы придумали свой крутой прокси изображений, и он как-то явно выходит за рамки вашей бизнес-логики приложения, более того возможно он пригодится в ваших других приложениях (или вы хотите поделиться с миром) делайте отдельный пакет.
Ну и конечно у таких пакетов, могут быть зависимости в виде других пакетов.
А вот прям делать декомпозицию приложения на пакеты, ради декомпозиции не стоит. Только если есть конкретный смысл что-то выделить.
Примеры вот хорошие у Spatie https://spatie.be/open-source?search=&sort=-downloads .
Там же можно посмотреть, как пакеты зависят друг от друга, например image от image-optimizer.
Все их, достаточно популярные, пакеты вышли из практики разработки приложений для клиентов.
Ближе к вашему примеру это проект Nova https://nova.laravel.com/ и тоже имеет кучу пакетов https://novapackages.com/ .
Но здесь тоже нужно учитывать, цели самой Nova и почему такая организация. Сама Nova это как бы расширяемый прототип панели управления для CRUD приложений, она универсальная by design, поэтому и нужны доп пакеты, которые закрывают конкретные цели.
Если у вас целевое приложение, то незачем его корневую бизнес логику куда-то выводить.

Laravel Sail всего лишь обёртка с командами чтобы быстро развернуть удобное докер окружение вокруг Ларавел.
Поэтому запускаете Docker Desktop и там можно посмотреть какие контейнеры и тп есть в системе. Там же можно быстро удалить.

Два цикла точно не нужны.
Где-то делаешь так, коллекцию из айдишников:

$postCategoriesIds = $post->categories->pluck('id')->all();

Ну и потом проверяешь входит ли айдишник в ту коллекцию.

foreach($categories as $category)
 <option value="{{ $category->id }}" @if($postCategoriesIds->contains($category->id)) selected @endif>{{ $category->name }}</option>
endforeach

Это вопрос старой боли с пробелами в конце и в начале(реже) вводимых пользователями в разных полях.
Проблема настолько часто встречалась, что обрезка пробелов была почти всегда в коде. Поэтому добавили такой функционал по умолчанию, одновременно кстати с установкой в null пустых строк. Что тоже повысило удобство.
Если нужно там можно писать исключения.