All of the previously loaded' error-messages suggest that somehow you have duplicates of those extensions installed in different locations, both of which SketchUp loads from.
Several of those causing errors are by other authors and are from other sources than SCF, and even some su_ shipped-extensions...

How are you installing your extensions ?

If you are copying files from one SketchUp version's Plugins folder into another. then it's a recipe for chaos.

If you download them from our PluginStore as RBZs and then use the Extension Manager to install them, then they automatically install in your default Plugins folder, from which SketchUp loads any extension .RB files it finds at startup. In your case it's
C:/Users/MSonmez/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins

If you use the ExtensionStore's dialog to auto-install them, that works without the need for the RBZ step, but they default to install in the same default Plugins folder.
However, you can opt to have your own personal destination folder, chosen and remembered with the ExtensionStore's Settings > Paths option. It's really only useful for those with a centralized folder used across SketchUp versions - you need to set up this alternative path using Fredo's AdditionalPluginsFolder tool.

An alternative path offered might be the Plugins folder in the ProgramData path, but this is only used for extensions shared between several users on the same computer, unlike your own user's Plugins folder personal to your login: it's typically used by more complex extensions like renderers etc. It does load its .RB files before the default Plugins folder so it could explain the duplication, but why all of your extensions seem to have arrived in there is a very unlikely mystery. It's not normally listed unless some previous installation [like a renderer] has made the Plugins folder for its .RB and subfolder...

If you can check for multiple Plugins folders and their duplicated contents it will help. Try to ensure only one version of each .RB and it's matching subfolder exist in any likely-to-be-loading Plugins folder.

Running this text in the Ruby Console will give you a list of all file-paths that are loaded from - BUT only the default ../AppData../Plugings would be normally listed in the ExtensionStore's Paths, never put extensions into another of these folders, unless you are really sure of what you are doing -
$LOAD_PATH
Please report back...

Step by step questions...
Can your IT guy get a cmd script to run at user's login ?
Can your IT guy then make that cmd script copy the license files from an admin-account's folder-structure into an equivalent folder in the user's account - e.g. '../appdata/local/scf licenses' ?
If this happens why can't the user then see the expected license files ?
I'm no cmd script guru. but surely your IT guys have some helpful ideas ??

e.g. If you manually copy over the license files from an admin-account's folder-structure into an equivalent folder in the user's account - e.g. '../appdata/local/scf licenses' - does that then work as expected ? If not, then why not ?

@ntxdave
The magnifying glass button is the first of the four icons at the right-hand end of the topmost title bar of the forum itself, NOT in the the title bar of the first post in a thread to the left of the 'Reply' button...

You've already learnt that you don't need to project the shadows of every element forming the building, or every plane that might catch a shadow.
Before you use the tool make a new tag to ultimately be an isolated set of geometry with the rest of the model 'off' - probably making two to reflect the original and modified forms.
then make a group that is assigned the appropriate tag.
Edit it and add simple faced 'box' shapes that follow the main external form of the building [used as a temporary underlay].
Only add in any wall, floor or roof faces etc, that will cast useful shadows.
You can probably ignore window-openings for a study this simple.
Do not include any 'rear' facing elements that won't cast meaningful shadows.
Do not include any wholly internal faces as they won't cast any useful shadows.
It should be relatively straightforward for you to work out which parts are needed - but the algorithm will look at everything.
Every superfluous bit of geometry which might not cast any meaningful shadows should be avoided -
because each one will still be pointlessly considered and processed before finally being ignored -
all of this only bloats the processing time exponentially and can lead to crashes as SketchUp becomes overwhelmed.
Perhaps an uploaded screen shot of the form, or even a simple skp showing what you've done so far, could elicit more useful advice...

Following on from @fredo6 's comment...
If each user logs in separately then surely a simple cmd script [written by your IT guys] auto-running at their login, could copy the needed license files over into their '../appdata/local/scf licenses' directory. Having this consistent location set up for everyone's folders/files should ease the license reading / validation ? Perhaps a logout cmd script could also run to tidy up and remove the no longer needed files, if thought appropriate ? ...

Perhaps @fredo6 would like to comment...

@Ramon3D

Several questions...

Does each of your students have a full copy of the the extension installed on their computer in their user's SketchUp Plugins folder ?
Also do they have a copy of the LibFredo6 installed on their computer in their user's SketchUp Plugins folder ? It's needed to support the extension.
And do they have a copy of the SketchUcation toolset installed on their computer in their user's SketchUp Plugins folder ? That's needed for the licensing.
Do they have a copy of the relevant license file saved onto their computer, and also has it been validated for that user and that device ?

@fredo6 will probably reply in more detail about the multi-seat licensing setup.

The recent update of our toolset sidesteps the particular startup error, but it won't stop the underlying issue of a badly installed extension causing issue - such as having a missing file causing an extension to miss out its version.
I assume from your explanation that you've deleted the Fredo extension's RB file AND its matching subfolder - and then the error was avoided.
If you install a fresh copy of it I presume that you no longer have an issue,
because the necessary file set will now be there,
and the Extension-Manager should then report it with its proper version info etc...

If it works in v2024 [see earlier posts] it'll probably work in v2026.
Try it.
To install an extension from a ZIP archive file rather than from an RBZ you will need either to change the file-type suffix, or even easier use the SketchUcation submenu item to install it from Archive, which works for both RBZ and ZIP archives...

The current LibFredo6 works with all recent versions of Sketchup.
There is also a legacy version in the PluginStore for older versions - i.e. <= v2016

What are 'the error messages' ?
A BugSplat or something else ?
What is your MAC OS ?

Select its icon and right-click > context-menu > Run as administrator.
A dialog opens, when prompted choose Repair.
This will fix any incorrect permissions etc that can cause unpredictable issue.
Restart SketchUp to see if anything has improved.
Repair will not affect any customization.
Double-clicking

@euljoo
Did you check your spam folder ?
Did you check https://sketchucation.com/webshop/my-licences.php ?
This lets you download copies of any license-files you have purchased.
After downloading a file to somewhere safe you can then validate it in the appropriate tool's menu item.

Version 5.0.6 is now available:
https://sketchucation.com/pluginstore?pln=SketchUcationTools

It's trapped for a very rare error [only one report to date!] which splatted the tool on loading, when it was checking an extension's version for the update report - if the user's installation of that extension's files is somehow incomplete - perhaps because of the use of su's migrate tool across versions glitch ? [Note: this principally affected just some of Fredo's and perhaps Thomthom's extensions, where Extension-Manager then lists it without a version etc and they were unloaded in the PluginsManager]

@rlgl

The error is currently a mystery to me.

It's showing an error for a missing file -
C:/Users/dvnj2/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/Fredo6_FredoSection/FredoSection.plugin

Checking I see that I do not get the same error message - everything works fine.
AND I also see that the .plugin file does exists in my Plugins folder.
If an extension is not loaded [when its version would be readily findable],
then because the version is not immediately got the ExtensionStore in checking your current extensions' versions has to try and get them in other ways.
A version is usually readable from an extension's registration xxx.RB file - even if it's been disabled using our Plugins-Manager.
But a couple of authors - like @fredo6 - don't set the version in that file,
but use a unique hash system to read their settings in from a xxx.plugin text file, kept in each extension's subfolder.
To the best of my knowledge all of Fredo's extensions use this method, as does this one.

I can force the same SketchUcation error as yours, by manually removing the FredoSection.plugin from its subfolder.

There are two cases:

1. FredoSection is set to be loaded in the PluginsManager - this error is sidestepped because the FredoSection extension is enabled in the Extension-Manager and its version is readable from the its properties. However, the Extension' properties all report as empty, and so no version etc could be read in. In this case the ExtensionStore defaults to thinking it's '0' and ignores its version.

2. FredoSection is set to be unloaded in the PluginsManager - this error is then thrown because the FredoSection extension is not now enabled in the Extension-Manager and its version is not readable from the its properties AND the .plugin file that would otherwise return the version is also not found. The error prevents the ExtensionStore from completing its version checking. This error could be sidestepped, but them you don't find out there's an issue with your FredoSection setup.

So this suggests to me that your installation of FredoSection extension is incomplete and the ../Fredo6_FredoSection/FredoSection.plugin is missing,
If you were not using the SketchUcation extension at all you would not get an error at startup, but just empty details in the ExtensionManager listing.
How did you install the FredoSection extension ?
If you have somehow copied files/folders from another Plugins folder this might have missed out vital files. Manual copying and the new su 'migration' tools can cause weirdness...

Please try reinstalling the extension and checking that ../Plugins/Fredo6_FredoSection/FredoSection.plugin file now exists, and the SketchUcation extension loads OK.
You can install from its RBZ using the Extension-Manager, download it from our PluginStore.
Alternatively you can close SketchUp, and find the file:
C:/Users/dvnj2/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/Fredo6_FredoSection.rb!
and rename it as:
C:/Users/dvnj2/AppData/Roaming/SketchUp/SketchUp 2026/SketchUp/Plugins/Fredo6_FredoSection.rb
i.e. without the ! at the end which was added to disable it.
After a restart this will allow SketchUcation's ExtensionStore to load and you can now use its dialog to reinstall the FredoSection extension, rather than using an RBZ.
See if the FredoSection.plugin file is installed properly and so on, and the the Extension-Manager now reports its proper details like author and version.
To stop even the currently faulty FredoSection file set from partially loading and tripping up the ExtensionStore you can use the Extension-Manager to disable the extension, rather than use the PluginManager.
A very remote possibility - if the .plugin file does indeed exist, but SketchUp can't find it, perhaps it is for some reason unreadable - so check its Security Properties.

The 'require' code that is unneeded doesn't break anything, just takes a millisecond to process and immediately ignore, slowing the loading time all but imperceptibly...

Have a good day too...

Thanks for the upload to the PluginStore/ExtensionStore.
I have Published it for you, so it's now available to all users.
I can see little to comment on - it works fine.
Note that require 'sketchup.rb' etc is not needed in any of your code, because, unlike older versions, it's now auto-required at startup as SketchUp loads, before your scripts are considered.

It's almost certainly OK on v2026 as far as it did with recent versions already - which was 'not faultlessly'.
But why not try it...

It is very old, but it works with v2026.
BUT there are several 'reverse face' tools available that are newer, less flaky, and probably better...
e.g. my own 'Fix Reversed Face Materials' which flips faces textured on their backs and reapplies the material, UV-mapping any textures to suit, and includes several other subitem tools to adjust reversed faces and their materials...

One further issue you should address before publishing this more widely - e.g. getting it 'signed' and in the EWH.
Its file naming does not follow the proper conventions.
An RBZ must contain just one .RB file that registers the extension and a folder of the exact same name.
Also the convention is to prepend the users 'name' at the start and even a sub-level if the modules do this.
So in your case there should be MendelAI_mesh_tools subfolder and a .RB file named MendelAI_mesh_tools.rb
You then edit the RB to load MendelAI_mesh_tools/loader

Because previous users might also now have the older badly named file/folder installer and loading you need to do some tidying up.
Add some code to the start of the RB to check for the existence of mesh_tools_loader.rb and mesh_tools subfolder in the Plugins folder -
use File.exist?(str) or better still similar methods in the fileutilities [which you need to 'require'] which will make deleting the subfolder and its contents much easier. So if these files exist you should also add a UI.message_box() to ask the user to restart to sync everything - next time the rogue file/folder won't be found and the code is redundant, but is still needed in any future updates in case a user has skipped this change in 1.0.2... A manual restart is preferable to a forced quit etc as the user might not have saved some work before updating etc.

@ntxdave
Showing back-edges can be useful in some modelling and presentations.
It's default View shortcut is K, but you can also toggled on/off in the Style dialog.