This is happening with Project Online but I recall it happening with Project Server as well. Whenever you create a Project Site template and associate it with an EPT, the notebook naming convention does NOT change. It maintains the original name. THis is confusing and it means that we can't name the template anything particularly unique because every Project Manager freaks out that the notebook is wrong. And, the question is as to whether or not the notes are all sitting on the one single file or if they are sitting in the actual project. Also, this happens REGARDLESS if "enable content" is checked when creating the Project Site template. The example attached is about how the template name stays attached to the notebook.

By default In Project Server 2016, the assigned Master Page for the PWA Instance is Seattle with Home word as a Site Title.

So I have tried to change the PWA Site Title through

- Site Settings > Look and Feel > Title,Description and Logo.

But unfortunately, The new Site Title is not changed as attached.

--------------------------------------------------------

By the way, The farm has been updated with the latest Cumulative update (Sept 2017) for SharePoint 2016 and looks like the issue still not solved!

--------------------------------------------------------

I mentioned all the detail at the below link and I also tried to introduce two workarounds to overcome this issue:

https://blog.devoworx.net/2017/09/24/project-server-2016-cant-change-the-site-title-in-seattle-master-page/

But we hope to get an official and permanent solution from the awesome Project Team.

Support for enterprise custom fields in the Project Client COM object model is minimal and has not changed much since 2000. Field access is not type-safe because everything with GetField and SetField methods is about strings and their input cell representation according to current Project configuration settings regarding date and duration formats as well as cost. Actually the value that is returned from GetField varies heavily depending on the options on how to represent the type that is used in the field. Reading enterprise custom flag fields is language-dependent (it's "Yes" or "No" or whatever the current language expressions for True and False are) which requires a lot of parsing and drops performance.
The actual data types can however be used when fields are written so that part is type aware so I see more need in support for reading the fields. While GetField always returns a string, how about a GetFieldValue method that returns a variant with the *actual* value that is behind the field I am reading? Not the formatted one as it is shown in the respective input cell. The output could be a String type for reading text fields, but should just as well be DateTime for date fields, an Integer (minutes) for work and duration fields, a Float or Currency type for cost and number fields, and a Boolean for flag fields. That would remove so much effort from all the customizing work that I am doing all day. And Project has the properly-typed values at hand all the time. I would no longer have to torture it to parse back strings that contain a date in the format that Project currently renders into date fields, just to get the value as a DateTime type.
By the way, project assignments have as good as no support at all for enterprise custom fields because the Assignment object does not expose any GetField or SetField methods, even though it is actually possible to write the fields in the usage views of the Project client's UI. So customers keep asking me how it is possible that they can freely edit and see custom fields on assignments whereas I cannot even see them in the code, let alone modify them.
The only way to access enterprise custom fields at all on assignments presumes their names do not contain any spaces. Then I can access them like the built-in assignment properties because Project mirrors the custom fields into the Assignment type interface through some obscure IDispatch hack. But basically I don't want to do that because field names are then part of the code, no longer part of the configuration, and the code will stop working the moment one of the fields does not exist or was renamed. Furthermore, many customers have a field naming convention that I would have to break just to make the fields accessible to the code. And most of them do not like FieldNamesWithNoSpacesInThem or Field_Names_Separated_by_Underscores. It's just not what the majority of users wants.
GetField/SetField (and of course GetFieldValue) methods for the Assignment type would solve this for good.

I would like to have a limit on the number of characters for a custom field. For example, I have a custom field, it is a number field but I want only 5 characters in length - the individual can enter up to five numbers but no more. This will ensure that the field matches what I need it to for reporting and for data validation. And, while we are at it, it would be great to have the ability to limit the minimum number of characters as well. In this example, I would want the minimum and maximum to both equal 5 - the users can only enter a 5 digit code. But, I have some other fields that could be a limit of 3 or maximum of 5 - the user can enter a value of 3,4,or5 characters ONLY>