I think it depends a lot on your specific application. In one centralized application, I think there may be a slight overlap between the Core and Common folders. But most importantly, it makes sense for your application. Do not feel that you need to have these folders just because you saw them in other applications ...
For me, having the Core and Common folders makes a lot of sense in some scenarios - for example, a web application with an API and a client. You can have your Core folder on the API side where the main execution is performed (business logic), and then there is the Common folder with some things that you need both in the API and on the client side - for example, Http asks for confirmation or Json converter.
In any case, it might make sense to have a Core and Common folder in other applications.
For example, the Core folder will contain those classes that are central to your application - the vast majority of business model classes will be there. On the other hand, in the Common folder, you can use other classes that are common, but not central - for example, Logger or MessageSender can be ...
As for your small code structure project, I think your Core package is the one to be reviewed - why is Lib1 not using Core ? If something is the core, it is usually because everything else needs it to run. If you don't have code that is conceptually central, maybe you can remove your Core package and save only Common ?
As for your other question, I don’t think that the Common stuff should be common to all other packages, but only with two or more packages that use something that can be considered common.