Strange use of Database Schema (Namespace) Database schema helps grouping tables, or help identify multiple tables that have the same table name. Most of the schema usage that I have found so far are for grouping tables, isolating tables among the users (or talents), allow different permission based on the schema.

In my case, I have a predefined table definition, and I like my user to be able to duplicate this table multiple times in my application. Obviously, I can't have the user create the new tables with the same name. My original idea is to allow the user specify a table name suffix:

e.g.
[TableA]
[CustomName_TableA]
[OtherName_TableA]


However, this requires a bit of code change since the table name is hardcoded in the data access layer of the application.

What are the drawbacks, or potential issues if I create a new schema when a user duplicate the table, instead of dynamically generate a new table name?

e.g.
[dbo].[TableA]
[CustomName].[TableA]
[OtherName].[TableA]
I really disagree with your statement that "database schema helps grouping tables, or help identify multiple tables that have the same table name." Actually database schemas were originally created to address security issues and security groupings. Unfortunately, in all of the worksplaces and projects I've been involved with, schema is synonymous with namesspaces (group names). This is just bad design in my opinion. 

You want to create a new schema for every user, but how many users will there be? You don't want 1000 schemas in your database. Schemas are registered in the metadata as unique objects, and there is a limit 2,147,483,640 - they are considered objects and the more objects you have the higher the overhead. The limits are set based on the SQL product you use. The number I gave was for SQL Server