PSR-0 or PSR-4, and how to properly build a project structure?

Question

PHP

Hello. I recently got acquainted with the standards for writing code and, to be honest, I got a little confused in their description.
The first question that interests me is PSR-0 or PSR-4. As far as I understand, as of October 21, 2014, PSR-0 was marked as obsolete. Currently, it is recommended to use PSR-4 as a replacement, but PSR-1 and PSR-2 refer to PSR-0, and I somehow did not find any Russian-language information about PSR-3, as if there is no such standard.
The second question is related to the hierarchy according to the PSR-0 or PSR-4 standard.
The examples include the following:

\Doctrine\Common\IsolatedClassLoader => /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php

\Symfony\Core\Request => /path/to/project/lib/vendor/Symfony/Core/Request.php

\Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php

\Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php

as far as I understand
/path/to/project/ is the path to the project and this path does not appear anywhere, this is the directory from which the main index.php is launched
./lib/ is the folder where I should store my libraries
./vendor/ is the folder the purpose of which I do not understand, since the supplier, as far as I understand, goes further
, in the end, as far as I understand, the path is built like this

<путь к проекту>/lib/vendor/<Наименование производителя>/(<Пространство имен>/)<Название класса>.php

this matches the namespace

<Наименование производителя>\(<Пространство имен>\)<Название класса>

but in other examples I have seen the following:
instead of "lib" they use "src" and there is simply no vendor directory.
or similar structure

vendor/
    vendor_name/
        package_name/
            src/
                Vendor_Name/
                    Package_Name/
                        ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                Vendor_Name/
                    Package_Name/
                        ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest

in the end, to be honest, I got confused about how to build my directories correctly, which folders are required and which are not, when to use src, when lib, when tests, why in some structures you have to specify the vendor name and package name twice, etc.
Most likely everything is very simple here, but for some reason it causes dissonance in examples from different sources.
Just in case, I will give an example of the hierarchy of my CMS system that I am developing:

./ROOT/ - ядро системы
./ROOT/classes/ - системные классы для работы ядра системы и дающие доступ к ядру из сторонних пакетов
./ROOT/configure/ - тут хранится все что связано с настройкой cms системы
./ROOT/kernel/ - тут лежат файлы самого ядра
./localization/ - тут лежат файлы локализации для системы и ее компонент и модулей. У них своя внутренняя иерархия.
./resources/ - тут лежат файлы ресурсов для работы компонент и модулей, а также все что получает cms система из вне или создает по средством работы самой системы, попадает сюда. Внутри каталога своя строгая иерархия.
./templates/ - тут лежат файлы с шаблонами страниц. к каждой странице сайта привязан один из этих шаблонов.
./components/ -компоненты. 
./components/<имя компоненты>/ - По сути это программа которая имеет выходной класс обязательно унаследованный от системного. Обеспечивает подключение к странице основного контента. Грубо говоря это то что отображается в зоне контента на странице. Может быть настроен для разных страниц по своему. Имеет закрепленный за ним набор обязательных и необязательных параметров и позволяет выбирать шаблон для отображения. Обязателен для страницы и может быть только один на странице.
./modules/ - модули
./modules/<имя модуля>/ - по сути схож с компонентами, за исключением того что располагается в определенных блоках шаблона для каждой страницы.
./plugins/ - плагины
./plugins/<имя плагина>/ - по сути это код который в явном виде не используется в системе, но добавляет ей дополнительные возможности, как например плагин который подключает на странице нужную библиотеку jqwery
./utilities/ - тут лежат утилиты для работы с системой, например утилита обновления, миграции данных, проверки на ошибки и т.д.
./lib/ - тут лежат библиотеки которые используются в модулях, компонентах и плагинах.
./lib/<имя поставщика>/<пространство имен>/<имя файла>.php (соответствует пространству имен <имя поставщика>\<пространство имен>\<имя файла>)
./index.php - основной файл который запускается при обращении к сайту. Он является обработчиком запросов, запускает ядро и возвращает результат.

Answer 1

The first question that interests me is PSR-0 or PSR-4. As far as I understand, as of October 21, 2014, PSR-0 was marked as obsolete.

PSR-4 is not a replacement for PSR-0, but an addition to it.
Apparently it hasn't been translated. Read original:
Yes, this is let to the PHP files of the project. But index.php is usually taken out to a separate directory (for example, / public), and all project classes are stored, for example, in / src (or / lib or whatever). The web server configuration prevents sending requests to any files not in /public, making /public/index.php the only entry point for external requests.
This is the folder for third party libraries used in your project. Used by composer. There is no particular reason to climb inside, the composer himself will decide how to arrange everything there. You should not write your classes there either.
src and lib are, shall we say, synonyms. Who likes it better. The main thing is that the PHP files of the project themselves are inside, following the PSR-4 standard. There are only files written by the authors of the project. So it doesn't make sense to put vendor inside src (or lib).
test - directory for project tests.
In the vendor folder, the name of the vendor and the name of the project may be the same, so they are duplicated.
Since you reinvent your wheel, make your own directory structure, or look at popular CMS / frameworks, but it will be different everywhere. Joomla , WordPress , Yii , Zend Framework , Symfony .
I follow this structure:

/config                     Глобальные настройки проекта.
/data                       Временные файлы. Например:
/data/cache	            Файлы кеша.
/data/logs	            Логи.
/data/tmp	            Прочие временные файлы.
/module                     Модули проекта. Например:
/module/Backend	        
/module/Backend/config      Настройки модуля.
/module/Backend/src	    Файлы PHP модуля. Например:
/module/Backend/src/Backend/Path/To/ExampleClass.php
/module/Backend/test	    Unit-тесты модуля.
/module/Backend/view	    Шаблоны модуля.
/module/Frontend/...
/public/index.php
/public/css
/public/font
/public/img
/public/js
/vendor

Perhaps I'm wrong, but your main problem is that you decided to develop your own CMS without working with existing ones, without identifying the advantages and disadvantages of their architectures and directory structures.