I am beginner to flutter/dart and has read that we don't have public/private/protected access specifier for dart but if we want to make private instance variable, we can make the use of underscore(_) operator but it will not make the variable private to the class but to its own library, So what does it actually mean ?
Dart privacy is indeed only on a per library basis.
A name which begins with _ is a library private name. A private identifier, like _tmp, is considered a different name than a similarly spelled identifier, also _tmp, which occurs in a different library.
That means that code in a different library cannot access the private name _tmp because it can't even express it. If it tries to write _tmp, it can only refer to a private name of its own library instead.
The choice of embedding access control in the name makes sense when you remember that Dart has dynamic invocations. If you write dynamic x = ...; x.foo();, then this should call the foo method of x if there is one. To do this efficiently, it would be too much of an overhead if each dynamic invocation should also figure out where the name originally comes from and whether it's accessible to the caller. Dart avoids this overhead by making all public names visible, and all private names inexpressible.
The goal of privacy is to separate public interface API from internal implementation API, and to avoid naming conflicts. You can write your private names without fear that they conflict with someone else's names, and without risking someone thinking they are meant for public use. Dart does not try to protect code from other code in the same library. It's supposed to be the same author anyway, so they can be trusted to use the API responsibly (and if not, it's on themselves).
What it means for you as a user is: The library is the unit of code. You can make libraries which contains only a single class. The library privacy is class privacy for that class. Or you can create libraries with many classes and top-level functions which can all see each other's private names.
That means you should base your modularity on the need of classes to share implementation, and not really anything else. You can always build a larger API by exporting other libraries.
When creating a Pub package, I would create your own internal libraries, inside the lib/src/ directory, giving them whatever size is convenient, and then export your public API from the package main file in lib/.