Hmm, I wonder, if it wouldn't make more sense to "finish" that feature, or at least to clarify, if it was meant to have a lookup functionality or not (if not, it should imho be documented, that it does not look up, if the title exists or not, thoguh)?

Maybe deprecating the function is clearer?

Yeah, IMO if there is no use case, just kill it.

@Tgr I have a usecase for the expected behavior . Specifically within MediaSearch where we are trying to replicate the Special:Search feature which serves the user a redlink to create a page when it doesn't exist.

Erm. No use case for checking whether a page exists? That seems improbable.

But, ok…

I have a (currently user script, eventually Gadget) for use with Proofread Page on English Wikisource. Proofread Page has a custom editing interface for the Page: namespace where a scanned book page is shown on the right, and on the left is a three-part editor. #wpTextbox1 is the main part labelled as "Body", and in addition it has textfields for "Header" and "Footer" that are meant for running headers and page numbers and similar (the stuff printed at the top and bottom of every page of a book). These headers and footers typically follow a pattern with the page number on the left on recto pages and on the right on verso pages; and in addition the book's title and the current chapter title are printed in the center on alternating pages.

My script automatically fills in this stuff based on some mw.config variables provided by the extension, and a manually set chapter title provided by the user (set manually when switching chapters and fetched from localStorage for other pages).

When I go back to previously transcribed pages belonging to a chapter other than the current one the script needs to check whether the page being edited already exists or not to determine whether I should update the running header or not. If the page already exists updating the running header will insert an incorrect chapter title.

I'm going to use wgArticleId (which returns 0 for pages that do not exist) to work around it for now, but this is kinda annoying. The alternative is faffing around with a lot of boilerplate and needless callbacks in order to ask mw.Api() whether the page exists. MediaWiki knows whether the page exists when it sends it to the UA so providing that information in an accessible way shouldn't be too too heavy. And if for whatever reason mw.Title couldn't get the information that way, having it abstract away the necessary call to mw.Api() so the user script / Gadget can just call mw.Title.exists() seems a straightforward interface.

In either case updating the documentation to say mw.Title.exists() currently always returns null would seem to be a no-brainer so users aren't left wasting time figuring out why it's failing. Or, put another way, the current documentation is incorrect because it claims the function can return either a boolean or null and in actuality it always returns null (no, sticking "if the information is available" in the docstring isn't enough; it implies there are times when the information is available).

In T184953#7232993, @Seddon wrote:

@Tgr I have a usecase for the expected behavior . Specifically within MediaSearch where we are trying to replicate the Special:Search feature which serves the user a redlink to create a page when it doesn't exist.

With the expected usecase being that it returns null? :)
The idea behind this method, I imagine, is to communicate title existence between unrelated parts of the code that don't necessarily know about each other. But I have yet to see code that sets any data in the title existence store.