Providing mocks as and when necessary about system.io.abstractions HOT 4 OPEN

I am not sure, I understand your use case, @sameera.

Do you use a mocking library like Moq or NSubstitute? If so, it should be easy to not use MockFileSystem at all and simply mock the IFileSystem or IFile interface itself.
Mixing the In-Memory Filesystem with a mock doesn't make sense to me, as you could then run in the situation that you write to a file via the mock and when you later read it from the In-Memory file system, you will get a FileNotFoundException.

from system.io.abstractions.

At a very high-level, the use case was to test that certain file operations are not being done over and over. So, we'd want our unit test to test that certain file system APIs (like File.ReadAllText) are not being called more than once. There are other file system operations along this execution path, so we don't want to have to replace all of them with mock code.
BTW, while I'm not yet fully familiar with this concept or library, it might be that Typemock's Isolators are a solution for this.

from system.io.abstractions.

The idea behind an In-Memory file system is, that it should behave (more or less) exactly like a real file system. If we would allow replacing single calls, this would result in much more complexity, as we could no longer rely on any consistent behavior. For this I would not like to introduce any (backward-incompatible) changes in the interface.

That being said, if I understand your use case correctly, you would like some "analytical" information about which method is called how often. This could be an interesting extension to the current MockFileSystem. If you would like to work on such a feature, I would be happy to discuss more details...

from system.io.abstractions.