The question of naming conventions is really opinion based. However, here are a couple of things closely related to your question that are worth discussing.
On a more general note, general "industry standard" naming conventions and coding styles (and tools such as various linters, etc.) should be secondary to the needs of you and your team, to the way you think about your problem domain, to your needs to express concepts in your design of actual code, and to the specific considerations you as a team have with respect to things like overall skill level, onboarding process, turnover rate, etc.
Following an "industry standard" naming convention (or project/folder structure) is not "more professional" (or less professional) then not doing so - it all depends on how much it actually benefits you. Everything is a tradeoff. You don't have to use Microsoft's recommendations as they are - sure, use them as a starting point, but you should adjust them as the need arises. Not doing so can even be detrimental. You are not Microsoft, you are not facing the same needs, challenges and constraints as they are.
For example, following an externally imposed set of rules too strictly might make important concepts in your code hidden and force you to do mental gymnastics, translating between the way you think about the problem, and the way you express it in your codebase. "The industry" is not going to read your code (even if you put it on GitHub), so don't write it for "the industry", that's not your audience. That's too broad to be useful. Write it to be understandable for your team, and people who might join your team. People who are steeped in the specific problem domain you're dealing with, or are prepared to learn about it. A group of people who have their specific way of working and thinking and tackling problems. If you're writing a library for others to use, write the external API to be understandable to the target audience, and write the internals to make sense (perhaps after reading some documentation) to people who already have some idea about this problem domain.
This gives you freedom both to express ideas and concepts in code more clearly, and to structure/design your code so that it's easier to work with and maintain. Following strictly a set of rules that's not necessarily well-suited for your needs is how, very systematically and very professionally, you get a codebase that's a tangled mess.
A project that's owned and developed by a team and a project that goes from one independent developer to another have different constraints in terms of how widely understandable / generic their code, coding style, folder structure, logical organization, etc. should be, at the expense of how far you can go beyond simple CRUD-like behavior before you run into a wall of complexity. Tradeoffs.
On a more specific note, regarding internal fields: sure,
_privateField._internalField might look strange, but that just tells you that you're not used to it. You should train yourself to be able to switch to / adopt different conventions anyway. Don't pay that much attention to the specific naming convention; instead, focus more on how the specific language feature is used, on the role it plays in your code.
You've said that you've been "using the common PascalCase for internal fields" - which is fine, but it also suggests to me that you've been, perhaps, treating internal fields more or less as public.
The internal access modifier is really just a crude, coarse-grained mechanism that allows for creating a component that spans two or three related, collaborating classes. An internal field is accessible among these classes, but should be treated as encapsulated in the overall component. It's the same old principles, just at another organizational level. You might want to do this if the class-level mechanisms can't quite express what you're trying to do, or because of considerations like performance, etc.
However, when it comes to other classes in the same assembly (classes that do not belong to this small collaborating cluster), this encapsulation entirely depends on (1) programmers being able to infer its there, and (2) on programmer discipline. Having an
_ as a prefix for both private and internal fields could serve as a crude workaround, a reminder that, when writing new code, you're potentially accessing a "component private" field, so that you can evaluate if such code should be refactored later on. Or it can serve as a prompt to check if there's perhaps a different way of doing the same thing that's more in line with the existing overall design.
My point is, if you adopt (or invent) a naming convention, it's a good idea to establish, as a team, some rationale behind it (or behind some of its aspects you deem relevant) that's based on the way you do work and on the needs of the project/team.