Дмитрий

Ну если внимательно взглянуть на документацию то что вы делаете в корне ей противоречит.

return [
           ['full_name', 'contacts'],
           ['', 'type', 'name',],
        ];

а после генерации файла - просто смерджить ячейки
$sheet->mergeCells('A1:B1');

Ваш код достанет все Post со всеми комментами в комментах которых отметился пользователь. Если вы хотите достать все посты в комментах которых отметился пользователь со всеми комменты только конкретного пользователя - то

$order = Post::with(['comments' => function ($q){
            $q->where('user_id',Auth::id());
        }])->whereHas('comments',function ($q){
            $q->where('user_id',Auth::id());
        })->get();

service = Service::select('id', 'name')->with(['users' => function ($query) {
$query->select('users.id', 'lastName', 'firstName')
}, ‘users.schedule’])->where('services.slug', $slug)->first();

Из коробки такой возможности я не знаю. Но чисто теоретически можно:
1. Расширить Builder и Model добавив туда метод withProps по аналогии с методом with и при отдаче моделей в методе hydrate или чего еще - устраивать магию.
2. Перенести в sql через какой нибудь scope - если не сложные вычисления то select *, upper(name) as upper_name вполне норм.
3. Самое любимое закостылировать (и здесь пойдут слайды):
В модели прописать

public function getPropAttribute(): string
    {
        return 'prop';
    }

    public function newInstance($attributes = [], $exists = false)
    {
        $model = parent::newInstance($attributes, $exists);
        $model->setAppends($this->appends);

        return $model;
    }

Вызов запроса усложнится

(new \App\Models\User())->setAppends(['prop'])->newModelQuery()->get()->first()->toArray()

^ array:8 [
  "id" => 2
  "name" => "Алексеев Глеб Дмитриевич"
  "email" => "fmarkov@example.com"
  "email_verified_at" => "2022-06-16T02:18:03.000000Z"
  "deleted_at" => null
  "created_at" => "2022-06-16T02:18:03.000000Z"
  "updated_at" => "2022-06-16T02:18:03.000000Z"
  "prop" => "prop"
]

З.Ы. Однако не могу не отметить - что скорее всего вы куда то не туда свернули, может вы расскажите задачу целиком?

1.public function destroy($id)
Используйте model binding - удобно же.

2. ProjectPolicy::requestDelete($id)
есть прекрасный вариант расставлять policy на уровне роутера - can:

Route::delete('/project/{project}', [Controller::class, 'method'])->can('delete', 'project');

3. $project = Project::find($id);
FindOrFail - в случае отсутствия модели выбросит ровно 404;

4. $this->deleteImageProject($project->logo);
Если вы всегда удаляете лого после удаления модели - то повесьте событие delete и всегда удаляйте лого как только где то и в каком то месте пытаются удалить модель Project. Для случаев mass delete - гляньте в трейт softDeletes, по аналогии можно навешать обработчик.
Лень - через события? Ну переопределите у модели метод delete.

public function delete()
{
    $result = parent::delete();
    if($result){
        $this->deleteImageProject($this->logo);
    }
    return $result;
}

У вас логика удаления модели (если нам надо удалить модель - надо удалить лого) - не должна валяться по всему проекту - она должна лежать в одном месте. А судя повсему вы ее вообще в контроллер запихали - ни в какие ворота

При использовании всего этого у вас метод контроллера приобретет простой и лаконичный вид.

public function destroy(Project $project)
{
    $project->delete();
    return response('', 204);
}

204 - ибо можем

If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted, a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied,
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status.

RFC

Запрос должен указывать что он хочет получить в ответ. У вас стоит - все что угодно. Если вы в Postman укажете что хотите получать в ответ JSON - Accept: application/json, вам будет отдавать json. Собственно если глянуть метод wantsJson это будет заметно.

З.Ы. но можно гвоздями в middleware прибить на api роуты $request->headers->set('Accept', 'application/json'); тогда вам будет похрен что там клиент хочет. Клиент всегда не прав!

class B extends Controller {
    public function beta(TestRequest $request, A $a)
    {
        dd($a->test($request));
    }
}

Простите за нескромный вопрос - а шо вы пытаетесь сделать?

Defing accessor

class Project extends Model{
............

public function getFullUrlAttribute(){
           return функция которая делает из атрибута полной путь();
}
.........
}

во вью {{$project->full_url}}

public functions questions(){

        $instance = $this->newRelatedInstance(Question::class);
        $localKey = $this->getKeyName();
        $query = $instance->newQuery()
             ->join('test_question', 'test_question.question_id', '=', 'questions.id')
             ->join('tests', 'tests.id', '=', 'test_question.test_id')
             ->join('lessons', 'lessons.id', '=', 'tests.lesson_id')
             ->join('modules', 'modules.id', '=', 'lessons.module_id')

        return $this->newHasMany(
            $query, $this, 'modules.course_id', $localKey
        );
}

Добавление этих заголовков через ларавел в случае того что Last-Last-Modified берется из атрибутов модели updated_at единственный выход.
В случае со статитикой лезть туда ларкой - такое себе, зачем nginx все сделает.

А так - регистрируете middleware, в контроллерах через какой нибудь singleton ServiceProvider передаете нужную дату. Если у вас route model binding - то можно наверное как то автоматизировать процесс. Но это надо копать
Можно тупо передавать примитивы через ServiceContainer https://laravel.com/docs/9.x/container#binding-pri...