Marking as Fixed and closing report.

Thinking about it a bit longer: Although rehashing the load path is an expensive operation that should be avoided if possible, it probably takes much less than 100 ms on most systems. (`tic, rehash(); toc` takes about 18 ms on my system. And that includes some time for the function call overhead.)

Starting a script from the editor (either with F5 or by clicking on one of the buttons or menu options), requires a human interaction. Adding a few milliseconds to the response time might not actually be critical.
(It would be more critical if this added time to calling things from a script or function.)

What do you think?

I appreciate all of your responses.

I wanted to make it clear that the issue appeared when I attempted to manually create a new m-file (not programmatically). I should have mentioned this earlier.

The question is: what was altered between this version and the previous release (8.4.0) that resulted in the appearance of this issue? given that I was not experiencing this issue before upgrading to version 9.1.0.

Thank you again.

-Roozbeh

Thanks for the pointer.

I don't see immediately what could be wrong with that. But everything load_path seems to be able to surprise me in one way or the other...

Found another way to work around the issue: Set a breakpoint in some line of the script (e.g., by clicking at that line in the left side bar) after it was saved but before executing it the first time with F5. In this case, the script starts executing and stops at the breakpoint as expected. It continues to be found on the load path also after the breakpoint is removed.

Is there a pattern? What happens to the load path when a function is executed from the command window and a break point is added to a new function (but not otherwise?)?

I don't know if it is related to comment #0. But I can confirm the behavior described in comment #2.
However, that only seems to happen when using F5 to run the newly created script immediately after it has been saved.
If I create and save a new script and then run it immediately afterwards by writing its name at the command prompt, it is working. After that, it also executes with F5 in the built-in editor.

`path(path())` seems to get the file to execute even after it failed to run with F5. `rehash()` doesn't help.

I don't know what actually happens when running a script from the editor with F5...

IIRC, Octave checks the last-modified time-stamp of folders in the load path when some conditions occur (e.g., the command prompt is displayed or the user changes the current directory). If this time-stamp updated since the last check, the containing files are rehashed.

It might be that none of those triggering conditions are reached when you programmatically create new m-files and try to execute them immediately.
It might also be that one of those triggering conditions is reached. But the last-modified time-stamp didn't update yet. (Windows is known to have a poor time-stamp resolution. It's also known that it doesn't correctly update time-stamps at all, e.g., on some shared file systems.)

It is hard to guess what is causing the particular issue that you are seeing as long as you don't provide any code that reproduces the issue for you. Could you please upload a minimum example that reproduces the issue?

Alternatively to relying on one of the "automatic triggers" for re-hashing the load path, you could try to manually trigger a rehash by calling the function `rehash()` after you created the new .m files.
Depending on the speed of file operations on your system, you might need to wait a bit after the file creation for it to be actually visible (e.g., using pause). (The latter might explain why you are seeing the issue in some versions of Octave but not in others: Maybe, some timings have changed?)