JhaoDa

$request->merge()

Но вообще, рекомендую открыть для себя такое понятие как form request.

Подписаться на событие deleting/deleted модели и выполнить распределение дочерних элементов между другими элементами.

Рекомендую поспать, потому что у тебя уже return'ы теряются в коде...

А поставить laravelcollective/html 5.6 кто-то запрещает?

https://www.google.com/search?q=laravel+419

Помедитируйте на строку

<img src="{{$post->getPrevious->getImage()}}" alt="">

Потом почитайте доку про связи. А потом либо используйте связи, как надо, либо не используйте вообще.
Заодно и про пагинацию почитайте, что бы не изобретать велосипед с квадратными колёсами.

https://github.com/laravel/framework/blob/5.6/src/...

Не очень понятно, от чего зависят условия, но есть как минимум два варианта: раз, два.

В комментариях выяснилось, что всё это выглядит весьма странно, но ладно...

Ну простое решение видится таким: аутентифицировали через auth:api, поймали событие Authenticated, в нём попытались аутентифицировать по auth:web. Получилось — всё отлично. Не получилось — не всё отлично.
Ну и можно проверить идентичность пользователей после обоих попыток, типа

\Auth::guard('api')->user()->is(\Auth::guard('web')->user());

Раз в N минут собирать собирать задания, которым скоро подойдёт срок. Ставить в очередь их удаление с точностью до минуты/секунды.

P.S. И поменьше тэгов.

Изучайте — https://github.com/laravel/framework/blob/5.2/src/...

А пробовали использовать правило так, как в документации предлагают?

Вы вообще хоть одним глазом в ридми заглядывали?

Не нравятся «глобальные» переменные, используйте вариант №2.

Не нравятся запросы в сервис-провайдерах, делайте их в каких-нибудь сторонних классах, а в сервис-провайдере вызывайте этот класс.
Либо пусть сервис провайдер обращается к какому-то классу и получает все нужные переменные для композинга.

Вариант №3: подписываться на события композинга самостоятельно и строить свою логику.